Re: Knowing if a GThread is still alive

[Jeff Johnston <jeff johnston mn gmail com>]

Thank you for the reply.

To kill the thread I am just going to offer a callback so that if a plugin wants to know if a thread is requesting to be killed that they can do the right thing. It does require the plugin writers to do the right thing and my program does not "manage" anything about the thread. Now my program just offers a way to see the running threads (that plugins kick off) and do a callback to tell the plugin that a thread is requesting to be killed. It is elegant although it puts the work on the plugin writers.

-Jeff

On Thu, Oct 4, 2012 at 1:18 PM, ternaryd <ternaryd gmail com> wrote:

On Thu, 4 Oct 2012 11:59:11 -0500
Jeff Johnston <jeff johnston mn gmail com> wrote:

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

I'm certainly not the official voice you are waiting for, but here are
some thoughts: There is a good chance (at least in Linux), that gthread
is a wrapper around posix threads (pthreads). If so, you can find the
thread's ID using "pthread_self(3)". Unless there is a more elegant way, you may want to call this at the beginning of the thread,
in order to make it available to the controlling thread. Once you want
to test if the thread is still alive, you can use pthread_kill(3)
with that ID and signal 0 (zero) and check for errors. This is
documented in the man-page. Of course, you can use another signal to
actually kill the thread, but this might not be such a good idea, as it
could lead to deadlocks or other unwanted side effects. A safer way to
do this, is to set some flag, signal, semaphore, etc. such that the
thread itself can perform some cleanup before exiting voluntarily.

HTH

_______________________________________________
gtk-list mailing list
gtk-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-list