[...]
> 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 - that means that the GTK+ code is
littered with calls to g_mutex_lock(), which are only effective when threads
are initialized.
So:
- start an app that doesnt use threads
- innocently load an evil evil library that does not assert that you are
already using threads, this evil library will typically go ahead and
initialize threads (THIS is IMO the root of most of the evil we are seeing,
the simple fact that libraries think its ok to just go ahead and initialize
threads).
Result:
- The library that initializes threads does it at some unpredictable point
in time, so if threads are not already initialized by the calling
application,
chances are that its getting initialized from inside of one of GTK+'s calls
to g_mutex_lock(), an ineffective lock... but after loading the library and
initializing threads... the following g_mutex_unlock() call is in
full effect,
in other words its just mass disorder when mixed with any library
(like GTK+),
that is thread aware and will make use of the threads/locks if
they are initialized.
Its basically a perfect recipe for disaster to initialize threads from a library
as some unpredictable point.
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.
Cheers,
-Tristan
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
