Re: [PATCH 0/4] Introduce scoped_ignore_signal & make it thread safe

[Pedro Alves <pedro@palves.net>]

On 2021-06-15 6:04 p.m., John Baldwin wrote:
> On 6/15/21 4:14 AM, Pedro Alves wrote:
>> For the Ctrl-C rework series I posted recently, I stared at code using
>> scoped_ignore_sigttou a lot, and it annoyed me that it isn't thread
>> safe, because it changes the signal's disposition.
>>
>> Very recently, we got a new scoped_ignore_sigpipe class modelled on
>> scoped_ignore_sigttou, which made me want to fix this before it ever
>> becomes a (hard to debug) problem.  I mentioned this here:
>>
>>   https://sourceware.org/pipermail/gdb-patches/2021-June/179958.html
> 
> I think this looks ok to me.  The one difference I can think of when
> using sigpromask() instead of SIG_IGN is if the signal might be
> sent to another thread instead of masked.  However, both SIGPIPE
> and SIGTTOU sent in the context of write() should be sent to the
> specific thread calling write().  SIGTTOU is a bit funky in that
> it gets raised to the entire process group, but in FreeBSD at least
> we only raise it if it is not masked for the current thread that
> has invoked write().  (If the signal is masked, it isn't raised at
> all.)

Yeah, I was a bit worried about that too, but what I observe on Linux
is the same as what you're describing for FreeBSD.

 - SIGTTOU isn't sent at all if the thread touching the terminal has it masked.

 - SIGPIPE is sent to the thread that writes and remains pending (hence
   the need for sigtimedwait).

     (confirmed that it was sent to the thread and now the process by inspecting
      the Sig* entries in /proc/TID/status.)

To double check that the kernel wouldn't send the SIGTTOU signal if some other
thread had it unblocked, I hacked GDB to make sure all GDB threads start
with signals unblocked:

--- c/gdbsupport/thread-pool.cc
+++ w/gdbsupport/thread-pool.cc
@@ -100,7 +100,7 @@ thread_pool::set_thread_count (size_t num_threads)
     {
       /* Ensure that signals used by gdb are blocked in the new
         threads.  */
-      block_signals blocker;
+      // block_signals blocker;

(and then confirmed by inspecting the Sig* entries in /proc/TID/status.)

If SIGTTOU ends up raised by some other thread while the main thread has it blocked
in scoped_ignore_sigttou, and if it is sent to the whole process, there's a small time window
where the sigtimedwait in the main thread can eat the signal.  That still seems better than
the current status where the end result can be that we can end up with the signal enabled
instead of ignored and then gdb backgrounds itself.  This is of course highly theoretical since I
expect that gdb threads run with signals blocked from the get go.  But you never know what
Python code does.