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.me...@novell.com <><, Pseudo Engineer, itinerant idiot
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
