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 <[email protected]>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 <[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
