[PATCH v2] Always pass signals to the right thread.

[Pedro Alves]

On 07/25/2014 10:34 AM, Eli Zaretskii wrote:
>> Date: Thu, 24 Jul 2014 16:40:42 +0100
>> From: Pedro Alves <palves@redhat.com>

>>> +@emph{Note:} When debugging multi-threaded programs, @var{signal} is
>>> +delivered to the currently selected thread, not the thread that last
>>> +reported a stop.  If for example the program last stopped on account
>>> +of a signal in thread 2 and you want to continue execution suppressing
>>> +that signal, you must have thread 2 selected as current before issuing
>>> +the @samp{signal 0} command.  @value{GDBN} detects the scenario and
>>> +asks for confirmation if you had switched threads meanwhile.
> 
> This description is IMO confusing, as it changes the described
> situation at least twice.  I suggest this text instead:
> 
>   @emph{Note:} When resuming a multi-threaded program, @var{signal} is
>   by default delivered to the currently selected thread, not the thread
>   that last reported a stop.  This includes the situation where a thread
>   was stopped due to a signal.  So if you want to continue execution
>   suppressing the signal that stopped a thread, you should select that
>   same thread before issuing the @samp{signal 0} command.  If you issue
>   the @samp{signal 0} command with another thread as the selected one,
>   @value{GDBN} detects that and asks for confirmation.
> 
> Otherwise, OK.

That looks great, thanks a lot!  Would you mind if I drop the "by default",
though?  When I read that I get the impression that there might be a knob
to configure this behavior, while there's none (and nor should there be one).
Like:

    @emph{Note:} When resuming a multi-threaded program, @var{signal} is
-   by default delivered to the currently selected thread, not the thread
+   delivered to the currently selected thread, not the thread
    that last reported a stop.  This includes the situation where a thread
    was stopped due to a signal.  So if you want to continue execution


Thanks,
Pedro Alves