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

["Havoc Pennington" <hp pobox com>]

Hi,

On Fri, Aug 15, 2008 at 5:55 PM, Brian J. Tarricone <bjt23 cornell edu> wrote:
> 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.
>

AIUI with gthread, in effect we have an init function with an argument
(threads_are_noop=true|false or more generally "set thread vtable")
and all libs must agree on this argument. It's global state set up at
init time.

In this design, setting the argument isn't allowed in libraries, only
in the app itself. Libraries run 'too late' to decide, they don't know
what other modules may have run. Only the app can ensure it decides at
the start of main().

Implication: libraries can't require threads, they have to work with
or without depending on what the app does. Or they have to require
that apps using the library specifically know the library will be
used, and init threads in order to use the lib.

If this is a problem (it kind of is) I'd argue that this global
setting is just a broken idea.

Possible solutions could be:
* make the setting per-library/per-module instead of global so
everyone can set it themselves
* remove the setting; threads are always enabled
* set a policy that only the app sets the setting, and libs/modules must conform
* set a policy that the thread-requiring library can't be used in
dlopen'd modules or otherwise when the app isn't expecting it, and the
app must init threads

But anyway, the bottom line is that args to init functions are in
effect global variables set by multiple people in undefined order,
unless you declare by policy who will set them...

For gthread surely the easiest is to just always init threads inside
g_mutex_new or the like.

Havoc