Re: [non-stop] 08/10 linux native support

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jun 25, 2008 at 10:23:18PM +0100, Pedro Alves wrote:
> A Wednesday 25 June 2008 22:17:25, Pedro Alves wrote:
> > Hmm, I was under the impression that it was possible to push more
> > than one SIGINT into a thread's signal queue, but I just tried it, and
> > it doesn't seem like it is.  This check was meant to prevent that
> > happening.
> 
> I'm confused.  It does seem I can put more than one SIGINT in the
> queue sometimes afterall.  (I just changed the code to do two kill's
> in a row instead of one).  If so, the check is needed to prevent the
> race where the thread hasn't reported the stop due to the SIGINT
> yet, so is_stopped is still false, and the user is doing "interrupt"
> on it (/me imagines user clicking a bunch of times on the IDE button).
> 
> The clearing on resume was just a safe place to always clear it.

Realtime signals can stack in the queue.  Non-realtime signals, like
SIGINT, can not.  Your first sigint is probably already delivered -
even though GDB hasn't waited for the program yet, this still counts
as dequeuing the signal.  Try three, and they won't stack.

The SIGINT is not necessarily the next signal to be received.  We
might get a SIGTRAP first, or anything else.  So the resume has
nothing to do with whether there's an "in-flight" SIGINT.  The same
complications as for SIGSTOP apply.

-- 
Daniel Jacobowitz
CodeSourcery