Re: glib thread create API

[Simon McVittie <simon mcvittie collabora co uk>]

On 09/11/13 15:38, Jonathan S. Shapiro wrote:
> The Mono implementation may have run into related issues. Mono uses both
> GLIB and GTK, but appears to use pthreads rather than glib threads. I'm
> not sure how they are mating the two, unless by incestuous knowledge of
> the glib implementation.

Is there any platform that has more than one flavour of threads, and has
to pick one per process otherwise everything breaks? If not, then this
is only a theoretical concern. If there is, I would tend to classify
that under "no, sorry, your platform is too crazy to use GLib".

(For instance, on Linux, pthreads threads and mutexes are implemented in
terms of clone() and futexes, GLib threads and mutexes are implemented
in terms of pthreads threads and a combination of futexes and atomic
operations, and they interoperate fine. On Windows, GLib threads and
mutexes are implemented in terms of the Win32 API, and if you have one
of the various pthread-win32 ports, it's *also* implemented in terms of
the same bits of the Win32 API, and should interoperate fine.)

It is not necessary that GLib's mutexes have a particular
implementation, as long as (a) they work, and (b) nobody tries to use
knowledge of their contents to lock them with non-GLib APIs.

If there's a platform where a "native" thread cannot block GLib threads
by locking the same GLib mutex held by those GLib threads, then I would
argue that the platform, or the port of GLib to that platform, or both,
are fundamentally broken.

> Also, can someone explain what happens when a glib thread runs off the
> end of its (arbitrarily sized) stack? I don't see behavioral
> documentation for that. :-)

There's no such thing as a GLib thread: if GLib is used on a platform
that has platform threads, a GLib thread is a platform thread. GLib does
not currently support platforms that don't have threads (it did in the
past).

Regardless, it's the same as happens when anything overflows its stack:
formally, "undefined behaviour", but probably SIGSEGV or platform
equivalent. Non-main threads are just more likely to overflow their
stacks, because they have to have a relatively small fixed-size stack.
The main thread's stack space is whatever portion of the process'
address space wasn't needed for the heap yet, so if the main thread
overflows its stack, something has already gone horribly wrong.

> Finally, is there a discussion anywhere on how to deal with situations
> where you have one block of code that really wants to use pthreads, and
> another that really wants to use glib/gtk?

IMO:

On platforms where the native API is pthreads (i.e. POSIX): use pthreads
if you want, that's what GLib does too.

On platforms where pthreads are a wrapper around some other primitive
that is also public API (e.g. Windows, if you have one of the various
pthreads-win32 ports): use either pthreads or the OS primitive, GLib
probably uses the OS primitive behind the scenes too.

On platforms where there's more than one OS primitive for threads and
you have to choose per-process otherwise everything blows up: admit that
you have two parallel ABIs, and build all your libraries twice, like you
would for 32- vs. 64-bit or for incompatible floating-point models. Or,
preferably, run away screaming, and tell everyone else to avoid that
platform too :-)

    S