Re: GIO will link with -pthread soon

[Michael Meeks <michael meeks novell com>]

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 ?

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

	Regards,

		Michael.

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