Reland r59511: Eagerly set the IO loop used for OCSP.

Reland r59511: Eagerly set the IO loop used for OCSP.

ChromeOS will create a special Profile for login.  Previously, OCSP initialization was done for the "default" ChromeURLRequestContext for each Profile.  Since we can have multiple profiles, this causes the initialization (and uninitialization) to happen multiple times, which causes problems for OCSP since we use statics.  The solution is to identify the "main" Profile.  We create said Profile in BrowserMain.  I add an "is_main_" variable to URLRequestContextGetter and URLRequestContext, so that only the "main" URLRequestContext will initialize OCSP.

Other than minor plumbing of "is_main_", this changelist is identical to r59511.

BUG=55940
TEST=Startup ChromeOS's Chrome.  Should not crash on startup.

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

[wtc, 2010-09-20 19:11:03]

LGTM.  Note the following two issues.

1. It would be nice to prevent the notion of "is_main" from
going into the network stack (specifically, the
net/url_request/url_request_context.{h,cc} files).  Is that
possible?

2. The notion of "main" needs to be defined better.  For example,
what is the "main" profile?  What is the "main" URLRequestContext?  Why does the
URLRequestContext for
OCSP have to be the main URLRequestContext?  I'm afraid
that I won't be able to maintain this code without
researching the relevant bugs and code reviews.

[willchan no longer on Chromium, 2010-09-20 19:52:57]

On 2010/09/20 19:11:03, wtc wrote:
> LGTM.  Note the following two issues.
> 
> 1. It would be nice to prevent the notion of "is_main" from
> going into the network stack (specifically, the
> net/url_request/url_request_context.{h,cc} files).  Is that
> possible?

Yes.  I'll follow up with a change to do this.

> 
> 2. The notion of "main" needs to be defined better.  For example,
> what is the "main" profile?  What is the "main" URLRequestContext?  Why does
the
> URLRequestContext for
> OCSP have to be the main URLRequestContext?  I'm afraid
> that I won't be able to maintain this code without
> researching the relevant bugs and code reviews.

As discussed offline, I've updated the comments.  I've done sone in
chrome/common/net/url_request_context_getter.h.  I plan to move all this out to
ChromeURLRequestContext{Getter} and fix up Profile to let this happen.  In the
future, I hope to establish more clearly the "main" Profile and its
corresponding ChromeURLRequestContext{Getter} objects.

[Craig, 2010-09-21 06:43:10]

I'm seeing lots of these after updating to r60017 btw.:

ERROR:net/ocsp/nss_ocsp.cc(536)] No URLRequestContext for OCSP handler.

I haven't backed out this patch yet but I think it might be related?

Spotted this too btw. ... should this be is_main_ = is_main; ?

void set_is_main(bool is_main) { is_main_ = true; }

Thanks!

[willchan no longer on Chromium, 2010-09-21 07:02:16]

I backed it out for causing chromiium os leaks.

On Mon, Sep 20, 2010 at 11:43 PM, <craig.schlenter@chromium.org> wrote:

> I'm seeing lots of these after updating to r60017 btw.:
>
> ERROR:net/ocsp/nss_ocsp.cc(536)] No URLRequestContext for OCSP handler.
>
> I haven't backed out this patch yet but I think it might be related?
>
> Spotted this too btw. ... should this be is_main_ = is_main; ?
>
> void set_is_main(bool is_main) { is_main_ = true; }
>
> Thanks!
>
>
> http://codereview.chromium.org/3470001/show
>

[wtc, 2010-09-21 17:33:40]

On 2010/09/21 07:02:16, willchan wrote:
> I backed it out for causing chromiium os leaks.

Sorry to hear that.

For the next relanding of this patch, please first create a CL
based on the reverted patch and immediately upload it, so that
Patch Set 1 of the new CL is the reverted patch and we will be
able to see your fix for Chrome OS leaks easily.  Thanks.