Re: bugs regarding late g_thread_init() calls

On 1/4/07, Tor Lillqvist <tml iki fi> wrote:
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.

I agree with this. If at all possible, fixing gslice to tolerate late
thread initialization is by far the best solution that will cause the
least problems for existing applications.

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.

This is very hard to do. You need a way to hook the g_thread_init()
call into the startup sequence. If you use an _init function or similar
mechanism, then your i_promise_no_threads() call will come too
late to prevent thread initialization...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]