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

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*


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