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 <rep...@bugs.python.org> <http://bugs.python.org/issue21645> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
