Re: bugs regarding late g_thread_init() calls

[Tim Janik <timj imendio com>]

On Tue, 2 Jan 2007, Martyn Russell wrote:

> Tim Janik wrote:

> > 2) Auto-initialize via g_thread_init (NULL) in gnome_init().
> >     + this has already been done for newer GNOME libs, see:
> >         http://bugzilla.gnome.org/show_bug.cgi?id=343490
>
> This is my idea of a temporary solution. It doesn't really address the
> issue properly.

it does, for all gnome programs. note that gnome_init() always used to call
g_thread_init(), just not always early enough.

> > 3) Auto-initialize with g_thread_init upon gtk_init
> >     + similar to gnome_init, gtk_init() could call:
> >         if (!g_threads_got_initialized)
> >           g_thread_init (NULL);
> >       this is not expected to be a problem for Gtk+ applications these days,
> >       and will fix too-late threading system initialization which is currently
> >       performed by file system backends of the new Gtk+ file selector.
>
> Again, this feels more like an after thought and not really the ideal
> solution here.

well, at this point there is no compelling reason for a gtk program to not
enable threading i think. especially since recent file chooser backends
have been reported to dmand-init threading anway (which is clearly
*always* too late).
so fallback initialization of threading in gtk_init() and friends sounds
like a non-intrusive change that gets rid of the problem for a lot of 
affected non-gnome apps.
do you have any concrete reason to object this?

> > 4) Patch up GSlice and other code to cope with late g_thread_init() calls
> >     + bug #331853 investigates this to some extend for GSlice, and it's
> >       probably possible, but requires significant implementation work.
> >     - however, other glib threading initialization portions still need to be
> >       evaluated wrg to supporting late g_thread_init() and may require more
> >       work.
> >     - even if it could be wokred out for all of the current glib systems,
> >       we can't be sure to be able to support arbitrarily late g_thread_init()
> >       calls in the future.
> >
> > at this point, i don't think (4) really has to be investigated/implemented,
> > and i don't see spare resources for it anyway.
> > however i'd like to propose the implementation of (3) to ease fixing of most
> > non-gnome gtk applications.
>
> I think the question that needs answering first is:
>
>  What in glib requires g_thread_init() to be called first?
>
> With my relatively limited experience of glib, all I can think of is:
>
>  - gasyncqueue
>  - gmain
>  - gthread
>  - gthreadpool
>  - gslice
>  - gtimer

off-head, there's are also threading initializers in glog and gmem.c.

i don't think this is a question properly phrased/answered though.
nothing in glib *needs* threading per se, except for dedicated
threading APIs (e.g. conditions, or async pools).
the question is whether all the threading aware code (which spreads
throughout all of glib, to make it thread-safe in general) can cope
with *late* g_thread_init() calls, and development has never focussed
on that. (we intentionally avoided that by demanding early calls to
g_thread_init if it is called at all.)

so unless you thoroughly audit all MT code, you can hardly be sure
you've caught all required cases.

> If it is a small portion of the code (i.e. just the few modules listed
> (above) then perhaps it should be initialised on demand.

that still bears the problem of figuring good entry points to demand
initialize on.

> However, if it
> is needed in a lot of places and/or the impact of calling
> g_thread_init() is relatively minor anyway,

there's a significant amount of setup code going on in that function.

> then perhaps a g_init()
> function is needed which we expect users to call first (like gtk_init())

GLib has so far supported the philosophy of not requirering an explicit
initialization call. mostly due to requests by Owen and a few others.

> I would probably vote for initialising on demand.

that'd have been ok for me as well, libgobject also requires that.
but it's simply too late to demand that at this point, such source+ABI
incompatible requirements can be introduced with 3.0 earliest.

> --
> Regards,
> Martyn

---
ciaoTJ