Re: Knowing if a GThread is still alive

[Jeff Johnston <jeff johnston mn gmail com>]

So, right now it seems that it is safe to say that a program really 
cannot know anything about other running threads (safely). Hopefully we 
can get an official word on this soon.

My idea of creating a thread and controlling it (on behalf of plugin) 
did not work. I did not understand that you can only exit the thread 
from within the created thread. So even though what I had kind of worked it was just too clunky to be useful. Still seems like it would not be too difficult to have a callback method to say when a thread finishes though.


-Jeff

On Mon, Oct 1, 2012 at 2:56 PM, Jeff Johnston <jeff johnston mn gmail com> wrote:

I must say that in my case I'm programming a library, and the thread which uses the library is not a thread I created myself, so I guess I can't add a g_thread_join() on it.

Yep, we are trying the same thing :). What I have is a method that takes in the same parameters as a thread (const gchar *name, GThreadFunc func, gpointer data).  And then in my library I create the thread and take control of it. If a user needed to get at the thread return value what I would need to do is have my API take a callback method (which I have not done yet).

This mostly worked out well for me. I do need to create the thread anyway because I have a visual way for the user to kill running threads, and I would need owership of the thread that started the process so I can kill it (per what the docs say). The downside is I essentially have two threads to do the work of one.

-Jeff

On Mon, Oct 1, 2012 at 2:41 PM, Vivien Malerba <vmalerba gmail com> wrote:

On 1 October 2012 21:09, Jeff Johnston <jeff johnston mn gmail com> wrote:

Good timing as I have this exact same question.

The problem is there is no "thread finalize callback" to use as that would be ideal. It seems the only way that you can know that a thread is done is by using g_thread_join, which causes the current thread to wait. So, for now, what I did was spin up a thread to handle the thread that I care about so I can wait for the other thread to finish using the g_thread_join method. Then I use a signal to tell me when that thread is finished (ie, gets passed the g_thread_join call).

Isn't it a bit dodgy if there is already another thread calling g_thread_join() on that same thread, as the doc says "Calling g_thread_join() from multiple threads for the same thread leads to undefined behaviour."? I must say that in my case I'm programming a library, and the thread which uses the library is not a thread I created myself, so I guess I can't add a g_thread_join() on it.

It would be nice to know what the official line on this is...the docs state "There are better ways to find out if your thread is still alive" but does not offer up what that better way is. It seems that a callback would be the most flexible way to handle it.

I agree, the doc needs to be more precise on these corner cases.

Regards,

Vivien