Re: thread cannot stop himself

Re: thread cannot stop himself

[Mark Kettenis]

Nicolas Vignal <nicolas.vignal@netline.fr> writes:

> Hello
> 
> I join a sample program with a thread who try to stop himself with a
> SIGSTOP.
> ( I know that is not the best way to do that ;-)
> It works fine in command line but not under gdb.
> gdb receive the signal and the flag pass to program is yes. But the thread 
> never stop.
> 
> Any idea of what happened ?

GDB uses SIGSTOP internally (for stopping threads) which interferes
horribly with your own use of the signal.  I'm loooking into a
solution, but things are pretty hairy, and I can't guarantee that I
find an acceptable solution to the problem.

For now, the only advice I can give you is: don't use SIGSTOP.  I'm
not sure what you're trying to accomplish by having a thread stop
itself, but there should be an alternative to using signals.  Try
using a mutex, semaphore or perhaps poll/select.

Mark

Re: thread cannot stop himself

[Nicolas Vignal]

Thanks for your answer, I found this messages in the mailing list 

http://sources.redhat.com/ml/gdb/2000-10/msg00001.html

still you ;-)

I will try to use less SIGSTOP but I need a way to stop threads.

Regards

	Nicolas

On Friday 09 February 2001 12:36, Mark Kettenis wrote:
> Nicolas Vignal <nicolas.vignal@netline.fr> writes:
> > Hello
> >
> > I join a sample program with a thread who try to stop himself with a
> > SIGSTOP.
> > ( I know that is not the best way to do that ;-)
> > It works fine in command line but not under gdb.
> > gdb receive the signal and the flag pass to program is yes. But the
> > thread never stop.
> >
> > Any idea of what happened ?
>
> GDB uses SIGSTOP internally (for stopping threads) which interferes
> horribly with your own use of the signal.  I'm loooking into a
> solution, but things are pretty hairy, and I can't guarantee that I
> find an acceptable solution to the problem.
>
> For now, the only advice I can give you is: don't use SIGSTOP.  I'm
> not sure what you're trying to accomplish by having a thread stop
> itself, but there should be an alternative to using signals.  Try
> using a mutex, semaphore or perhaps poll/select.
>
> Mark