> > 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 <[email protected]> wrote: > > > On 1 October 2012 21:09, Jeff Johnston <[email protected]> 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 [email protected] https://mail.gnome.org/mailman/listinfo/gtk-list
