I did my meditation. I now understand the race:

- main thread is blocked in select() (or poll() etc.)
- C-level signal handler is called in thread B and writes a byte to self-pipe
- kernel immediately switches threads
- main thread wakes up, reads data from self-pipe, goes back to block
- C-level signal handles calls Py_AddPendingCall() to schedule Python-level signal handler
- however the main thread is already back asleep

The intention if the code was that the Py_AddPendingCall() would complete before the thread switch. Perhaps a CPython fix could be to call it before writing a byte to the pipe??? But that would require someone else to meditate more on the C code.

I think your patch to Tulip is fine. I wouldn't worry about missing a signal when things are busy -- AFAIK the child process reaper will reap multiple processes.