Re: GIO will link with -pthread soon

[Tristan Van Berkom <tvb gnome org>]

On Tue, Nov 17, 2009 at 1:11 PM, Michael Meeks <michael meeks novell com> wrote:
> Hi Tristan,
>
> On Mon, 2009-11-16 at 14:34 -0200, Tristan Van Berkom wrote:
>> > Michael wrote:
>> > fact by the threading system ? [ I was never persuaded that glib's
>> > demand to initialize threads before any other line of code was remotely
>> > reasonable either BTW ;-]
>>
>> Its really very simple.
>>
>> Consider that GTK+ is thread aware
>
>        Notice the 'glib' in my above sentence :-) The GSlice allocator - which
> ( last I recall ) was the rational for not allowing late g_thread_init
> has no tricky callbacks, and can (IMHO) cf. abortive patch discussion
> here - 4th Jan 2007, be made to work quite easily. The glib mainloop
> already seems to have some basic late-init support creating the wakeup
> pipe etc. and I don't believe we hold a lock over glib mainloop dispatch
> - instead acquiring / releasing the context. So is there a problem
> there ?

Right, I was quite convinced that historical thead initialization by way
of libgnomeui, or even further by modules - was the main reason
for this mandate, mostly because of the gdk lock.

>> Its also the reason why, if we were to include gthread in GIO, essentially
>> GIO would have to assert that threads are initialized, in any case it would
>> be another no-no to go ahead and blindly initialize GThread from the GIO
>> code, unless we could always ensure that GIO is the first to initialize in
>> any given process.
>
>        Well - IMHO there is a big difference between GDK threads and allowing
> late gthread init. GDK threads init is something that few do or wants to
> do; whereas recovering gracefully from the loading of a module that
> wants to use threading in conjunction with the mainloop seems like a far
> more useful thing.

Hmmm im not so sure, are there cases where an application somewhere
along the line wants to conditionally use threads ?

Theres also a big difference to be noted between a late thread initialization,
and unsuspected thread initialization done under the hood as a result
of loading some library or module.

For instance:
 - initialize library A { library A checks that threads is not
initialized, and operates in single threaded mode)
 - initialize library B { library B was uneducated about threads, and
just calls g_thread_init() if they are not
                                 already initialized }

In this scenario your library A can run into some problems, which can only
be solved by the calling application initializing threads before
initializing library A and B
(so in the end, "before any other line of code"... is almost the same
in most of all the
cases I can think of).

On the other hand, maybe its library A that needs to understand how to fall on
its feet when there is a brutal thread initialization somewhere down the line
and library A wants to all of a sudden create some locks and stuff...
that in itself
sounds pretty complex to pull off.

While the GSlice allocator storing some per-thread data and getting messed
up across g_thread_init() might be a fixable bug (albeit that code does look
complex), is it worthwhile fixing to gain the flexibility of calling
g_thread_init()..
only a few lines further down the road ?

Cheers,
       -Tristan

Thanks for keeping me on my toes this morning Michael ;-)

>
>        Regards,
>
>                Michael.
>
> --
>  michael meeks novell com  <><, Pseudo Engineer, itinerant idiot
>
>