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@xxxxxxxxx> wrote:
On 1 October 2012 21:09, Jeff Johnston <jeff.johnston.mn@xxxxxxxxx> 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
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
