[issue21645] asyncio: Race condition in signal handling on FreeBSD

[Guido van Rossum]

Guido van Rossum added the comment:

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.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21645>
_______________________________________