[Cronet] Avoid crashing when CronetEngines are created on multiple threads

[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
Committed: https://crrev.com/b20cd0fe76a4e163920ecf8ab7f9fbb9ed39c9ec
Cr-Commit-Position: refs/heads/master@{#390738}

[pauljensen, 2016-04-27 14:55:48]

pauljensen@chromium.org changed reviewers:
+ mef@chromium.org

[pauljensen, 2016-04-27 14:55:48]

Misha, PTAL.

[kapishnikov, 2016-04-27 15:53:17]

kapishnikov@chromium.org changed reviewers:
+ kapishnikov@chromium.org

[kapishnikov, 2016-04-27 15:53:18]

Should we do the same check in the constructor of ChromiumUrlRequestContext?

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
File
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java
(right):

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:72:
public static void ensureMainThreadInitialized(Context context) {
Don't need to be public.

[pauljensen, 2016-04-27 16:08:55]

On 2016/04/27 15:53:18, kapishnikov wrote:
> Should we do the same check in the constructor of ChromiumUrlRequestContext?

Not needed as it doesn't directly execute on main thread.

[mef, 2016-04-27 16:43:47]

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
File
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java
(right):

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:23:
// Has library loading commenced?  Setting guarded by sLoadLock.
add @GuardedBy?

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:26:
private static boolean sMainThreadInitDone = false;
Maybe call it sInitDone?

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:72:
public static void ensureMainThreadInitialized(Context context) {
Maybe call it 'ensureInitializedOnMainThread'? 
It doesn't just initialize main thread.

[pauljensen, 2016-04-27 16:56:42]

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
File
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java
(right):

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:23:
// Has library loading commenced?  Setting guarded by sLoadLock.
On 2016/04/27 16:43:47, mef wrote:
> add @GuardedBy?

I read it in an assert on another thread and I don't want it to require locking
just for the sake of an assert.

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:26:
private static boolean sMainThreadInitDone = false;
On 2016/04/27 16:43:47, mef wrote:
> Maybe call it sInitDone?

I'd rather not as this variable is very specific to the main thread, and
shouldn't be accessed on other threads (so I like the fact that it has main
thread in its name).  If you feel strongly let me know and I'd be glad to change
it.

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:72:
public static void ensureMainThreadInitialized(Context context) {
On 2016/04/27 15:53:17, kapishnikov wrote:
> Don't need to be public.

Done, also done for ensureLibraryLoaded.

https://codereview.chromium.org/1926683003/diff/1/components/cronet/android/j...
components/cronet/android/java/src/org/chromium/net/CronetLibraryLoader.java:72:
public static void ensureMainThreadInitialized(Context context) {
On 2016/04/27 16:43:47, mef wrote:
> Maybe call it 'ensureInitializedOnMainThread'? 
> It doesn't just initialize main thread.

Done.

[kapishnikov, 2016-04-27 17:30:09]

I think there is still a possibility for the client to start calling
CronetUrlRequestContext methods before ensureMainThreadInitialized() method has
finished. Let's assume that the client executes the following lines on a worker
thread:

CronetEngine engine = CronetEngine.Builder.build();
UrlRequest req = engine.createRequest();

Since CronetUrlRequestContext() will be called on the worker thread but
CronetLibraryLoader.ensureMainThreadInitialized() is posted on the main thread,
CronetUrlRequestContext() can finish before ensureMainThreadInitialized() even
started to execute.

Thus, the client code will be able to call engine.createRequest() before
ensureMainThreadInitialized() started the execution.

Can it potentially cause a problem?

If it can cause a problem, what if we block ensureInitialized() until
initialization is complete regardless whether it is the main or a worker thread?

[pauljensen, 2016-04-27 17:50:19]

On 2016/04/27 17:30:09, kapishnikov wrote:
> I think there is still a possibility for the client to start calling
> CronetUrlRequestContext methods before ensureMainThreadInitialized() method
has
> finished. Let's assume that the client executes the following lines on a
worker
> thread:
> 
> CronetEngine engine = CronetEngine.Builder.build();
> UrlRequest req = engine.createRequest();
> 
> Since CronetUrlRequestContext() will be called on the worker thread but
> CronetLibraryLoader.ensureMainThreadInitialized() is posted on the main
thread,
> CronetUrlRequestContext() can finish before ensureMainThreadInitialized() even
> started to execute.
> 
> Thus, the client code will be able to call engine.createRequest() before
> ensureMainThreadInitialized() started the execution.
> 
> Can it potentially cause a problem?
> 
> If it can cause a problem, what if we block ensureInitialized() until
> initialization is complete regardless whether it is the main or a worker
thread?

This is not directly related to this CL or bug.  This problem relates to
dependencies between two pieces of code meant to run on the main thread, not
between the main thread initialization and other thread dependencies on it. 
Please file a new bug so we can discus there.  I don't mean to write off your
concern, I agree with your concern on this other matter, I just want this P1
crash fix to land ASAP so I'd rather not side-track the discussion.

[kapishnikov, 2016-04-27 18:12:01]

On 2016/04/27 17:50:19, pauljensen wrote:
> On 2016/04/27 17:30:09, kapishnikov wrote:
> > I think there is still a possibility for the client to start calling
> > CronetUrlRequestContext methods before ensureMainThreadInitialized() method
> has
> > finished. Let's assume that the client executes the following lines on a
> worker
> > thread:
> > 
> > CronetEngine engine = CronetEngine.Builder.build();
> > UrlRequest req = engine.createRequest();
> > 
> > Since CronetUrlRequestContext() will be called on the worker thread but
> > CronetLibraryLoader.ensureMainThreadInitialized() is posted on the main
> thread,
> > CronetUrlRequestContext() can finish before ensureMainThreadInitialized()
even
> > started to execute.
> > 
> > Thus, the client code will be able to call engine.createRequest() before
> > ensureMainThreadInitialized() started the execution.
> > 
> > Can it potentially cause a problem?
> > 
> > If it can cause a problem, what if we block ensureInitialized() until
> > initialization is complete regardless whether it is the main or a worker
> thread?
> 
> This is not directly related to this CL or bug.  This problem relates to
> dependencies between two pieces of code meant to run on the main thread, not
> between the main thread initialization and other thread dependencies on it. 
> Please file a new bug so we can discus there.  I don't mean to write off your
> concern, I agree with your concern on this other matter, I just want this P1
> crash fix to land ASAP so I'd rather not side-track the discussion.

The CL looks good. I was just thinking that making ensureInitialized() call
synchronous would solve both problems (they are related in some sense, i.e.
ensureInitialized() is not completed before a method that assumes its completion
is called). This CL definitely solves the above mentioned bug and can be
submitted before we implement some other solution.

[pauljensen, 2016-04-27 18:16:15]

On 2016/04/27 18:12:01, kapishnikov wrote:
> On 2016/04/27 17:50:19, pauljensen wrote:
> > On 2016/04/27 17:30:09, kapishnikov wrote:
> > > I think there is still a possibility for the client to start calling
> > > CronetUrlRequestContext methods before ensureMainThreadInitialized()
method
> > has
> > > finished. Let's assume that the client executes the following lines on a
> > worker
> > > thread:
> > > 
> > > CronetEngine engine = CronetEngine.Builder.build();
> > > UrlRequest req = engine.createRequest();
> > > 
> > > Since CronetUrlRequestContext() will be called on the worker thread but
> > > CronetLibraryLoader.ensureMainThreadInitialized() is posted on the main
> > thread,
> > > CronetUrlRequestContext() can finish before ensureMainThreadInitialized()
> even
> > > started to execute.
> > > 
> > > Thus, the client code will be able to call engine.createRequest() before
> > > ensureMainThreadInitialized() started the execution.
> > > 
> > > Can it potentially cause a problem?
> > > 
> > > If it can cause a problem, what if we block ensureInitialized() until
> > > initialization is complete regardless whether it is the main or a worker
> > thread?
> > 
> > This is not directly related to this CL or bug.  This problem relates to
> > dependencies between two pieces of code meant to run on the main thread, not
> > between the main thread initialization and other thread dependencies on it. 
> > Please file a new bug so we can discus there.  I don't mean to write off
your
> > concern, I agree with your concern on this other matter, I just want this P1
> > crash fix to land ASAP so I'd rather not side-track the discussion.
> 
> The CL looks good. I was just thinking that making ensureInitialized() call
> synchronous would solve both problems (they are related in some sense, i.e.
> ensureInitialized() is not completed before a method that assumes its
completion
> is called). This CL definitely solves the above mentioned bug and can be
> submitted before we implement some other solution.

When you say "making ensureInitialized() call synchronous" do you mean waiting
on the main thread task to complete?  I think that will introduce deadlocks.  As
the Chromium threading doc discusses: "Another thing to watch out for is to not
block threads on one another"

[kapishnikov, 2016-04-27 18:27:26]

On 2016/04/27 18:16:15, pauljensen wrote:
> On 2016/04/27 18:12:01, kapishnikov wrote:
> > On 2016/04/27 17:50:19, pauljensen wrote:
> > > On 2016/04/27 17:30:09, kapishnikov wrote:
> > > > I think there is still a possibility for the client to start calling
> > > > CronetUrlRequestContext methods before ensureMainThreadInitialized()
> method
> > > has
> > > > finished. Let's assume that the client executes the following lines on a
> > > worker
> > > > thread:
> > > > 
> > > > CronetEngine engine = CronetEngine.Builder.build();
> > > > UrlRequest req = engine.createRequest();
> > > > 
> > > > Since CronetUrlRequestContext() will be called on the worker thread but
> > > > CronetLibraryLoader.ensureMainThreadInitialized() is posted on the main
> > > thread,
> > > > CronetUrlRequestContext() can finish before
ensureMainThreadInitialized()
> > even
> > > > started to execute.
> > > > 
> > > > Thus, the client code will be able to call engine.createRequest() before
> > > > ensureMainThreadInitialized() started the execution.
> > > > 
> > > > Can it potentially cause a problem?
> > > > 
> > > > If it can cause a problem, what if we block ensureInitialized() until
> > > > initialization is complete regardless whether it is the main or a worker
> > > thread?
> > > 
> > > This is not directly related to this CL or bug.  This problem relates to
> > > dependencies between two pieces of code meant to run on the main thread,
not
> > > between the main thread initialization and other thread dependencies on
it. 
> > > Please file a new bug so we can discus there.  I don't mean to write off
> your
> > > concern, I agree with your concern on this other matter, I just want this
P1
> > > crash fix to land ASAP so I'd rather not side-track the discussion.
> > 
> > The CL looks good. I was just thinking that making ensureInitialized() call
> > synchronous would solve both problems (they are related in some sense, i.e.
> > ensureInitialized() is not completed before a method that assumes its
> completion
> > is called). This CL definitely solves the above mentioned bug and can be
> > submitted before we implement some other solution.
> 
> When you say "making ensureInitialized() call synchronous" do you mean waiting
> on the main thread task to complete?  I think that will introduce deadlocks. 
As
> the Chromium threading doc discusses: "Another thing to watch out for is to
not
> block threads on one another"

Yes, the thread should wait until the initialization is complete; otherwise, it
can start calling methods on uninitialized object. We are already using
"synchronized" keyword in this method. The only difference is that the thread
that posts the runnable will block until the runnable is finished., i.e.

            // Run task immediately or post it to the UI thread.
            if (Looper.getMainLooper() == Looper.myLooper()) {
                task.run();
            } else {
                // The initOnMainThread will complete on the main thread prior
                // to other tasks posted to the main thread.
                new Handler(Looper.getMainLooper()).post(task);
                taskIsDone.block(); <---- new change !!!!!
            }

Inside the runnable task we should call: taskIsDone.open() in the finally block.

This should not cause any deadlock problems... I guess.

[pauljensen, 2016-04-27 18:29:50]

On 2016/04/27 18:27:26, kapishnikov wrote:
> On 2016/04/27 18:16:15, pauljensen wrote:
> > On 2016/04/27 18:12:01, kapishnikov wrote:
> > > On 2016/04/27 17:50:19, pauljensen wrote:
> > > > On 2016/04/27 17:30:09, kapishnikov wrote:
> > > > > I think there is still a possibility for the client to start calling
> > > > > CronetUrlRequestContext methods before ensureMainThreadInitialized()
> > method
> > > > has
> > > > > finished. Let's assume that the client executes the following lines on
a
> > > > worker
> > > > > thread:
> > > > > 
> > > > > CronetEngine engine = CronetEngine.Builder.build();
> > > > > UrlRequest req = engine.createRequest();
> > > > > 
> > > > > Since CronetUrlRequestContext() will be called on the worker thread
but
> > > > > CronetLibraryLoader.ensureMainThreadInitialized() is posted on the
main
> > > > thread,
> > > > > CronetUrlRequestContext() can finish before
> ensureMainThreadInitialized()
> > > even
> > > > > started to execute.
> > > > > 
> > > > > Thus, the client code will be able to call engine.createRequest()
before
> > > > > ensureMainThreadInitialized() started the execution.
> > > > > 
> > > > > Can it potentially cause a problem?
> > > > > 
> > > > > If it can cause a problem, what if we block ensureInitialized() until
> > > > > initialization is complete regardless whether it is the main or a
worker
> > > > thread?
> > > > 
> > > > This is not directly related to this CL or bug.  This problem relates to
> > > > dependencies between two pieces of code meant to run on the main thread,
> not
> > > > between the main thread initialization and other thread dependencies on
> it. 
> > > > Please file a new bug so we can discus there.  I don't mean to write off
> > your
> > > > concern, I agree with your concern on this other matter, I just want
this
> P1
> > > > crash fix to land ASAP so I'd rather not side-track the discussion.
> > > 
> > > The CL looks good. I was just thinking that making ensureInitialized()
call
> > > synchronous would solve both problems (they are related in some sense,
i.e.
> > > ensureInitialized() is not completed before a method that assumes its
> > completion
> > > is called). This CL definitely solves the above mentioned bug and can be
> > > submitted before we implement some other solution.
> > 
> > When you say "making ensureInitialized() call synchronous" do you mean
waiting
> > on the main thread task to complete?  I think that will introduce deadlocks.

> As
> > the Chromium threading doc discusses: "Another thing to watch out for is to
> not
> > block threads on one another"
> 
> Yes, the thread should wait until the initialization is complete; otherwise,
it
> can start calling methods on uninitialized object. We are already using
> "synchronized" keyword in this method. The only difference is that the thread
> that posts the runnable will block until the runnable is finished., i.e.
> 
>             // Run task immediately or post it to the UI thread.
>             if (Looper.getMainLooper() == Looper.myLooper()) {
>                 task.run();
>             } else {
>                 // The initOnMainThread will complete on the main thread prior
>                 // to other tasks posted to the main thread.
>                 new Handler(Looper.getMainLooper()).post(task);
>                 taskIsDone.block(); <---- new change !!!!!
>             }
> 
> Inside the runnable task we should call: taskIsDone.open() in the finally
block.
> 
> This should not cause any deadlock problems... I guess.

That sort of thing has a good chance of causing deadlocks, e.g. if the main
thread is already waiting on the worker thread.  This is why the Chromium
threading design doc discourages blocking threads on other threads.

[mef, 2016-04-27 18:48:15]

https://codereview.chromium.org/1926683003/diff/20001/components/cronet/andro...
File
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java
(right):

https://codereview.chromium.org/1926683003/diff/20001/components/cronet/andro...
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:1142:
CronetEngine cronetEngine = builder.build();
Can we create and start a new request here, before opening otherThreadDone?
If I understand Andrei's concern, there is a good chance of running into issues
here because library is still not initialized.

https://codereview.chromium.org/1926683003/diff/20001/components/cronet/andro...
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:1147:
otherThreadDone.block();
OTOH I can see Paul's point that this will deadlock if otherThread would wait
for init to complete on main thread.

[pauljensen, 2016-04-27 19:04:24]

https://codereview.chromium.org/1926683003/diff/20001/components/cronet/andro...
File
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java
(right):

https://codereview.chromium.org/1926683003/diff/20001/components/cronet/andro...
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:1142:
CronetEngine cronetEngine = builder.build();
On 2016/04/27 18:48:15, mef wrote:
> Can we create and start a new request here, before opening otherThreadDone?
> If I understand Andrei's concern, there is a good chance of running into
issues
> here because library is still not initialized.

We could do lots of things here.  I think our other tests cover creating a
CronetEngine and UrlRequests on a non-main thread quite well.  This test
triggers the crash I'm concerned with.

[kapishnikov, 2016-04-27 19:36:26]

Maybe it is okay for the client to call CronetEngine methods before
nativeCronetInitOnMainThread() is executed. We should double check it. Meanwhile
LGTM to unblock the bug fix.

[mef, 2016-04-27 19:50:00]

lgtm for the fix of reported crash, although I would like to verify that it
would not crash one line after when app starts the request or net log.

https://codereview.chromium.org/1926683003/diff/20001/components/cronet/andro...
File
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java
(right):

https://codereview.chromium.org/1926683003/diff/20001/components/cronet/andro...
components/cronet/android/test/javatests/src/org/chromium/net/CronetUrlRequestContextTest.java:1142:
CronetEngine cronetEngine = builder.build();
On 2016/04/27 19:04:24, pauljensen wrote:
> On 2016/04/27 18:48:15, mef wrote:
> > Can we create and start a new request here, before opening otherThreadDone?
> > If I understand Andrei's concern, there is a good chance of running into
> issues
> > here because library is still not initialized.
> 
> We could do lots of things here.  I think our other tests cover creating a
> CronetEngine and UrlRequests on a non-main thread quite well.  This test
> triggers the crash I'm concerned with.

Acknowledged.

[pauljensen, 2016-04-27 20:02:00]

On 2016/04/27 19:50:00, mef wrote:
> lgtm for the fix of reported crash, although I would like to verify that it
> would not crash one line after when app starts the request or net log.

I bet the NCN registration silently fails, but I don't envision a crash.

[pauljensen, 2016-04-27 21:03:07]

The CQ bit was checked by pauljensen@chromium.org

[commit-bot: I haz the power, 2016-04-27 21:03:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1926683003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1926683003/20001

[commit-bot: I haz the power, 2016-04-27 21:48:55]

Committed patchset #2 (id:20001)

[pasko, 2016-04-28 10:47:15]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1927863004/ by pasko@chromium.org.

The reason for reverting is: CronetUrlRequestContextTest#testSkipLibraryLoading
fails on public cronet bots:

http://crbug.com/607464.

[pauljensen, 2016-04-28 16:38:06]

Description was changed from

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

to

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

[pauljensen, 2016-04-29 01:25:49]

The CQ bit was checked by pauljensen@chromium.org

[pauljensen, 2016-04-29 01:25:50]

The patchset sent to the CQ was uploaded after l-g-t-m from
kapishnikov@chromium.org, mef@chromium.org
Link to the patchset: https://codereview.chromium.org/1926683003/#ps40001
(title: "sync")

[commit-bot: I haz the power, 2016-04-29 01:26:03]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1926683003/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1926683003/40001

[commit-bot: I haz the power, 2016-04-29 02:19:28]

Description was changed from

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

to

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

[commit-bot: I haz the power, 2016-04-29 02:19:29]

Committed patchset #3 (id:40001)

[ccameron, 2016-04-29 17:57:52]

On 2016/04/29 02:19:29, commit-bot: I haz the power wrote:
> Committed patchset #3 (id:40001)

I have reverted this in
https://codereview.chromium.org/1934623002
because it was on top of a patch that I wanted to revert. Sorry for the
inconvenience!

[pauljensen, 2016-04-29 18:57:01]

Patchset #3 (id:40001) has been deleted

[pauljensen, 2016-04-29 18:57:23]

Description was changed from

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

to

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

[pauljensen, 2016-04-29 19:45:22]

The CQ bit was checked by pauljensen@chromium.org

[commit-bot: I haz the power, 2016-04-29 19:45:42]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1926683003/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1926683003/20001

[commit-bot: I haz the power, 2016-04-29 20:18:55]

Description was changed from

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

to

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

[commit-bot: I haz the power, 2016-04-29 20:18:56]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-04-30 17:13:38]

Patchset 2 (id:??) landed as
https://crrev.com/aa99c6902d3ec652f37bc38bcc6862f83ed3deae
Cr-Commit-Position: refs/heads/master@{#390204}

[commit-bot: I haz the power, 2016-04-30 17:23:52]

Patchset 2 (id:??) landed as
https://crrev.com/315ed9b17216bff1847dce29ecae62828e09ead8
Cr-Commit-Position: refs/heads/master@{#390576}

[commit-bot: I haz the power, 2016-04-30 17:28:22]

Patchset 2 (id:??) landed as
https://crrev.com/b20cd0fe76a4e163920ecf8ab7f9fbb9ed39c9ec
Cr-Commit-Position: refs/heads/master@{#390738}

[commit-bot: I haz the power, 2016-04-30 17:52:16]

Description was changed from

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178
==========

to

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178

Committed: https://crrev.com/aa99c6902d3ec652f37bc38bcc6862f83ed3deae
Cr-Commit-Position: refs/heads/master@{#390204}
==========

[commit-bot: I haz the power, 2016-04-30 17:59:07]

Description was changed from

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178

Committed: https://crrev.com/aa99c6902d3ec652f37bc38bcc6862f83ed3deae
Cr-Commit-Position: refs/heads/master@{#390204}
==========

to

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178

Committed: https://crrev.com/315ed9b17216bff1847dce29ecae62828e09ead8
Cr-Commit-Position: refs/heads/master@{#390576}
==========

[commit-bot: I haz the power, 2016-04-30 18:02:13]

Description was changed from

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178

Committed: https://crrev.com/315ed9b17216bff1847dce29ecae62828e09ead8
Cr-Commit-Position: refs/heads/master@{#390576}
==========

to

==========
[Cronet] Avoid crashing when CronetEngines are created on multiple threads

Creating a CronetEngine on one thread calls
CronetLibraryLoader.ensureInitialized() which posts to the main thread, but
if a CronetEngine is created immediately after this on the main thread without
first returning to the message loop, that initialization won't have happened
and the initialization of the CronetEngine being created on the main thread
could crash when it tries to get the current native MessageLoop.

BUG=607178

Committed: https://crrev.com/b20cd0fe76a4e163920ecf8ab7f9fbb9ed39c9ec
Cr-Commit-Position: refs/heads/master@{#390738}
==========