Re: When to call g_thread_init(), again...

["Brian J. Tarricone" <bjt23 cornell edu>]

Havoc Pennington wrote:

> If the init function does have arguments, then you end up with a
> requirement that all libraries and modules calling it must call it
> with the same args ... which isn't possible ... so init functions with
> arguments are broken unless the *app* and never a library will always
> call the init function.

... which, if you can't avoid an init function, is what I'd advocate, 
because...

> All the gthread functions seem to check g_thread_supported() anyway
> which is just the variable g_threads_got_initialized, so they could as
> easily do "if (!g_threads_got_initialized) { g_thread_init(NULL); }"

This breaks for libraries that require locking in threaded programs but 
(obviously) not in non-threaded programs.  You can get into a situation 
where you call a lock() without threads initialised, then something 
somewhere (whether in glib or a 3rd party lib) goes and calls 
g_threads_init() because it thinks it needs it (even if it doesn't, 
because the program isn't threaded), and then you call unlock(), and it 
breaks.  This is the example tml brought up with GtkHtml.

Init functions suck, sure, I'll agree.  But it appears we're stuck with 
one in gthread, so I'd advocate tightening up the library (or any 
libraries that use gthread) so it actually enforces what the docs say, 
even if some existing apps get semi-broken as a result.  Cuz, arguably, 
they're already broken and just waiting for a hard-to-find error to pop up.

Now I'll go fix one of my libraries that behaves contrary to what I just 
described...  *hangs head in shame*

	-brian