Re: bugs regarding late g_thread_init() calls
- From: Tor Lillqvist <tml iki fi>
- To: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: bugs regarding late g_thread_init() calls
- Date: Thu, 4 Jan 2007 14:09:00 +0200
Michael Meeks writes:
> Of course, the argument "it was always like that" is perhaps
> better, though Owen suggests it wasn't always :-)
Indeed it wasn't. GNOME programs have been calling tons of GLib
functions before gnome_program_init() eventually called
g_thread_init() for ages without ill effects, as far as I know.
So, as much as I hate saying this, I think that it is too late now
starting crashing if g_thread_init() is called too late. It's our own
fault. When we introduced a requirement like that, we should have
*enforced* it.
In my opinion what needs to be done is this: GLib should normally
always be threaded (behave as if g_thread_init(NULL) had been called
at the very start of main()), and g_thread_init(NULL) will thus turn
into a no-op.
Then, for the benefits of those few apps that really are sure they
won't ever create threads, introduce a new function:
g_i_promise_no_threads(). This function, if called at all, should be
called before calling any other GLib function. (And this time, check
that the promise is held, and if it isn't, crash and burn.)
--tml
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]