Jingle_glue bugfixes.

Jingle_glue bugfixes.

Fixed Closed() methods in JingleChannel and JingleClient so that they are 
not blocking and guarantee that callback is not called afterwards.
Changed JingleThread shutdown mechanism so that the thread doesn't stop until
all tasks are finished.
JingleClient now uses LocalTunnelSessionClient that allows local connections.

BUG=52889
TEST=unittests

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=57770

[Alpha Left Google, 2010-08-26 21:55:01]

The code looks good. Is it possible for to add tests for jingle_client and
jingle_channel so we can test the tear down?

[Sergey Ulanov, 2010-08-27 00:58:55]

On 2010/08/26 21:55:01, Alpha wrote:
> The code looks good. Is it possible for to add tests for jingle_client and
> jingle_channel so we can test the tear down?
Added new tests for both JingleClient and JingleChannel.

[Alpha Left Google, 2010-08-27 22:45:15]

awsome. LGTM.

[Timur Iskhodzhanov, 2010-08-29 16:28:49]

Sergey, please watch the Memory waterfall after commiting to remoting/libjingle.
TSan bots report data races (maybe, benign) on all three platforms.

Please take a look at the reports and file appropriate bugs/commit suppressions.
I'd be good if you add me to the cc so I can verify on Monday.

[Sergey Ulanov, 2010-08-30 19:23:55]

Timur,
Is it possible to automate failure handling for the memory waterfall? I.e.
if there is new failure it could automatically send e-mail the people who
committed changes in the interval when the new issue was introduced. This
would avoid the need to watch the memory waterfall after every check-in
(waste of time for everybody) and you wouldn't have to nag me every time
something fails due to my check-in. It would be even better if the bots
could automatically create a bug and add suppressions if a failure doesn't
get fixed in a certain period of time. Can this be implemented?

On Sun, Aug 29, 2010 at 9:28 AM, <timurrrr@chromium.org> wrote:

> Sergey, please watch the Memory waterfall after commiting to
> remoting/libjingle.
> TSan bots report data races (maybe, benign) on all three platforms.
>
> Please take a look at the reports and file appropriate bugs/commit
> suppressions.
> I'd be good if you add me to the cc so I can verify on Monday.
>
>
> http://codereview.chromium.org/3167047/show
>

[Timur Iskhodzhanov, 2010-08-30 19:46:16]

I'd love to, see http://code.google.com/p/chromium/issues/detail?id=51585
Unfortunately, I'm not a buildbot guru to implement it myself :-(

Looks like libjingle/remoting produces more reports per commit just because it
actually deals with threads, without Chromium "mostly single-threaded" model.

Do you use ThreadSanitizer locally? Do you use linux_tsan trybots?
Probably it can help you in development and local testing.

On 2010/08/30 19:23:55, sergeyu wrote:
> Timur,
> Is it possible to automate failure handling for the memory waterfall? I.e.
> if there is new failure it could automatically send e-mail the people who
> committed changes in the interval when the new issue was introduced. This
> would avoid the need to watch the memory waterfall after every check-in
> (waste of time for everybody) and you wouldn't have to nag me every time
> something fails due to my check-in. It would be even better if the bots
> could automatically create a bug and add suppressions if a failure doesn't
> get fixed in a certain period of time. Can this be implemented?
> 
> On Sun, Aug 29, 2010 at 9:28 AM, <mailto:timurrrr@chromium.org> wrote:
> 
> > Sergey, please watch the Memory waterfall after commiting to
> > remoting/libjingle.
> > TSan bots report data races (maybe, benign) on all three platforms.
> >
> > Please take a look at the reports and file appropriate bugs/commit
> > suppressions.
> > I'd be good if you add me to the cc so I can verify on Monday.
> >
> >
> > http://codereview.chromium.org/3167047/show
> >
>