Re: bugs regarding late g_thread_init() calls

[Martyn Russell <martyn imendio com>]

Tim Janik wrote:
>> 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?

I do agree that there is no compelling reason for a gtk+ program to not
enable threading though - that seems perfectly fine. However, I would
rather only call g_thread_init() for special implementations and have
glib initialise it for me if I don't call it first. This seems more
logical to me and also means that it is up to us when we call
g_thread_init().

>> 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.)

And even now I think that is a good way of doing it. If we stick to
this, I think having the g_thread_init() in gtk+ actually is a good idea.

I think you either do that or have an initialisation function which
allows the programmer to choose when calling _init() to enable threading
or not (which should mean late thread initialisation would no longer be
an issue).

>> 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.

Is there any reason not to do this? I mean, I remember when I first
started writing applications and it seems strange that glib didn't
follow suite with gtk+, gnomevfs, etc. Also with talks of gnomevfs
moving closer to glib, would you need an initialisation function ay some
point anyway?

The only other similar base library implementation I have used was in my
last job and we did have an _init() function and you could specify a
bunch of options, one of which was to enable threading (by default it
was disabled). If this approach was taken, then gtk+ could still call
g_init() with some variable to enable threading.

>> 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.

Having a g_init() function is a much cleaner and more non-intrusive
method of doing this. It makes more sense to me actually, I think you
know (from a programmers point of view) if you are going to have
threading enabled and that decision is best made as early as possible is
it not? Would you ever want to call g_thread_init() late in a program's
execution?

-- 
Regards,
Martyn