linux: call g_thread_init() at relevant startup points

linux: call g_thread_init() at relevant startup points

According to glib docs, we need to do this if it's at all possible
for us to hit glib on multiple threads.  This may be happening
when we grab plugin metadata from the file thread.

Rather than explicitly depending on gthread all over the place,
just put it in with the GTK dep (since anywhere we're using GTK
we ought to init gthread).

(Note that this is *not* initializing the GDK locking system.)

BUG=18957

[Evan Martin, 2009-08-21 22:37:54]

can't hurt, right?

[willchan no longer on Chromium, 2009-08-21 22:47:01]

On 2009/08/21 22:37:54, Evan Martin wrote:
> can't hurt, right?

I haven't looked at the code yet, but one higher level question.  Now that
estade's fixed the other multithreading issue with IconLoader, there's only the
plugin one left.  In the long run, we want to grab plugin metadata in a separate
process anyways, right?  So, is this a temporary fix?

I imagine there's a small, probably negligible cost to g_thread_init(), since
glib will have to lock access to all glib globals.  We shouldn't have any
contention, but we'll still have to pay the locking cost.  It's probably
negligible, but it's worth noting the cost is non-zero.

I'll take a look at the code itself in a sec.

[Evan Martin, 2009-08-21 23:05:39]

On 2009/08/21 22:47:01, willchan wrote:
> plugin one left.  In the long run, we want to grab plugin metadata in a
separate
> process anyways, right?  So, is this a temporary fix?

Not sure.  If this fixes the problem, then I think we're ok -- in theory we're
grabbing metadata from these plugins because we intend to actually load them.

> 
> I imagine there's a small, probably negligible cost to g_thread_init(), since
> glib will have to lock access to all glib globals.  We shouldn't have any
> contention, but we'll still have to pay the locking cost.  It's probably
> negligible, but it's worth noting the cost is non-zero.
> 
> I'll take a look at the code itself in a sec.

[piman, 2009-08-21 23:14:39]

LGTM.

[willchan no longer on Chromium, 2009-08-21 23:18:29]

lgtm2

[willchan no longer on Chromium, 2009-08-21 23:32:21]

On Fri, Aug 21, 2009 at 4:05 PM, <evan@chromium.org> wrote:
> On 2009/08/21 22:47:01, willchan wrote:
>>
>> plugin one left. =A0In the long run, we want to grab plugin metadata in
>
> a separate
>>
>> process anyways, right? =A0So, is this a temporary fix?
>
> Not sure. =A0If this fixes the problem, then I think we're ok -- in theor=
y
> we're grabbing metadata from these plugins because we intend to actually
> load them.

Just checking...if we actually load them though, it'd be in the plugin
process, right?

>
>
>> I imagine there's a small, probably negligible cost to
>
> g_thread_init(), since
>>
>> glib will have to lock access to all glib globals. =A0We shouldn't have
>
> any
>>
>> contention, but we'll still have to pay the locking cost. =A0It's
>
> probably
>>
>> negligible, but it's worth noting the cost is non-zero.
>
>> I'll take a look at the code itself in a sec.
>
>
>
> http://codereview.chromium.org/174264
>

[Evan Martin, 2009-08-24 20:20:31]

please re-review, i had to rejigger deps (and updated the description)

[Dean McNamee, 2009-08-24 20:29:34]

Just wanted to confirm, are we seeing these crashes in the browser or
plugin process?  I guess the browser, and that's where we query the
metadata?

On Mon, Aug 24, 2009 at 1:20 PM,  <evan@chromium.org> wrote:
> please re-review, i had to rejigger deps (and updated the description)
>
> http://codereview.chromium.org/174264
>

[Evan Martin, 2009-08-24 20:30:27]

> > Not sure. =A0If this fixes the problem, then I think we're ok -- in theor=
> y
> > we're grabbing metadata from these plugins because we intend to actually
> > load them.
> 
> Just checking...if we actually load them though, it'd be in the plugin
> process, right?

Well, "load" is a loaded word.  We have to dlopen() and call a function in them
in both the browser and renderer process, but the actual initialization etc is
only ever done by the renderer.

[Evan Martin, 2009-08-24 20:32:54]

Yep.

On Mon, Aug 24, 2009 at 1:25 PM, Dean McNamee<deanm@chromium.org> wrote:
> Just wanted to confirm, are we seeing these crashes in the browser or
> plugin process? =A0I guess the browser, and that's where we query the
> metadata?
>
> On Mon, Aug 24, 2009 at 1:20 PM, =A0<evan@chromium.org> wrote:
>> please re-review, i had to rejigger deps (and updated the description)
>>
>> http://codereview.chromium.org/174264
>>
>

[piman, 2009-08-24 20:51:35]

lgtm