Fwd: glib thread create API

["Jonathan S. Shapiro" <shap eros-os org>]

On Mon, Nov 11, 2013 at 4:49 AM, Simon McVittie
<simon mcvittie collabora co uk> wrote:
> Is there any platform that has more than one flavour of threads, and has
> to pick one per process otherwise everything breaks?...


Simon:

Much of what you are saying here makes sense. That still leaves me
needing to use the native thread API directly because I need to
control the size and location of the stack, which glib doesn't
support.

Given what you say, I think that gets my questions down to the
behavior of g_thread_self(), which returns a value that cannot be
passed to other g_thread routines (without signaling in any way that
is has done this dastardly thing). I was initially hopeful that this
might just be a doc issue, but on reflection I see why it needs to be
so. In particular, things like g_thread_join() can't sensibly call
g_thread_unref() on an alien gthread.

I'm very much of the view that simple things should be simple, so I
actually *like* the g_thread_new() API just as it is. I do think a
variant should exist to set the stack size, but maybe that's a use
case that is rare enough that it doesn't warrant "first class" support
in the API. An awful lot of thread libraries over the years have been
forced to add that one after the fact, so I'm skeptical, but I don't
have a clear enough use case to warrant suggesting a change to the
API.

> > 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.

As an implementation matter, I understand that this is true. As an API
matter, it's clearly false, because g_thread_self() is explicitly
documented to silently return an invalid GThread* value if the calling
thread was not allocated by g_thread_new(). Reconciling this would
resolve every concern that I presently have.

By "reconciling", I don't necessarily mean that the glib code base has
to change. If I feel a need to mess with pthreads (or whatever)
directly, the onus to make that work with glib should probably be on
me. This could be purely a matter of documentation. In that case, it
would be helpful if glib might export just enough API to let me manage
the issue (and no more).

The only issue I see - and I haven't looked at the internal GThread
structure to see if this is addressed already - is that the thread
teardown behavior would need a callback mechanism so that "alien"
threads can be torn down properly.

Oh. And if g_thread_self() can return invalid answers without
signaling, I think the API needs g_thread_is_gthread(), which returns
true IFF the thread was allocated by g_thread_new(). The fact that
this call even warrants consideration kinda illustrates why the
current behavior of g_thread_self() isn't a good thing.


shap