Re: Fwd: glib thread create API

[Ryan Lortie <desrt desrt ca>]

hi,

On Tue, Nov 12, 2013, at 11:09, Jonathan S. Shapiro wrote:
> 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.

Here's some insight into what's going on here:

When you call g_thread_new() you get a reference to a GThread*
structure.  When the thread is created, it stores a pointer to this
thread structure into a thread-local variable.  That's what is returned
when you call g_thread_self().

If you call g_thread_self() and this thread-local variable is found to
be empty, then you get a GThread structure whipped-up on the spot and
returned to you.

So each GThread object in existence is owned by:

 - the thread itself (via its thread-local variable)
 - the person who got a reference from g_thread_new()
 - anyone else who added a reference to it

The GThread object that is created implicitly by access to
g_thread_self() in a thread that was not created by GLib (including the
main thread) is perfectly valid for most things -- you can pass it
around, ref it, do comparisons on it, etc.

The things that you should not do to this are the things that are
limited to the lifecycle control of the thread itself -- things like
joining it.  It should be fairly obvious that since you did not use a
GLib API to create a thread then you should not use our API to collect
it, either.

Other than that, there really are no GThread APIs left to speak of, so
there is really no difference in what you can do (outside of the
exceptions mentioned above).

btw: I don't think that having the teardown APIs unsupported on these
implicitly-created GThread is a weird thing.  The person who wants to
tear down the thread is probably the person who called _new() on it
anyway -- and in this case nobody called _new()...

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

Would it help if we documented something along the lines of "On
non-Windows systems, the threads created with this API are pthreads?"

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

We don't want this, as mentioned above.

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

As mentioned, the GThread returned from this API is completely legit.

Cheers