Re: [PATCH 7/9] Enqueue signal even when resuming threads

[Pedro Alves <palves@redhat.com>]

On 06/30/2016 03:09 PM, Yao Qi wrote:
> Nowadays, we only enqueue signal when we leave thread pending in
> linux_resume_one_thread.  If lwp->resume->sig isn't zero (GDB wants
> to resume with signal), we pass lwp->resume->sig to
> linux_resume_one_lwp.
> 
> In order to reduce the difference between resuming thread with signal
> and proceeding thread with signal, when we resume thread, we can
> enqueue signal too, and proceed thread.  The signal will be consumed in
> linux_resume_one_lwp_throw from lwp->pending_signals.

This makes one subtle change.  If the thread already
had a pending signal, and we're getting a resume request with
a signal that is a different signal from the one already queued,
then before the patch, we'd tell the kernel to deliver the new
signal first, and then only deliver the pending signal the next time
the thread is resumed.  While after the patch, we'll enqueue the
new signal, and deliver the one that was already pending first.

Can't really say whether the old behavior was necessary.  At least
the new behavior seems to make order or signal delivery consistent
with how the order the signals were made pending in the
first place, so seems better.

This made me notice that this scenario of having more than one
pending signal doesn't seem to be handled perfectly.  We deliver
the first signal, but nothing makes sure to get back control
of the thread immediately in order to deliver the other pending
signal, so it seems the thread may execute a bunch of arbitrary code
until it next stops and is re-resumed, at which point we'll deliver
the other pending signal.  Maybe the simplest would be to
force the thread to immediately stop again, by calling
send_sigstop before resuming it, whenever we have more pending
signals.  Subject for a separate patch, in any case.

Thanks,
Pedro Alves