This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients giampaolo.rodola, gvanrossum, pitrou, python-dev, vstinner, yselivanov
Date 2014-07-17.15:13:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2014-07-17 15:13:38gvanrossumsetrecipients: + gvanrossum, pitrou, vstinner, giampaolo.rodola, python-dev, yselivanov
2014-07-17 15:13:38gvanrossumsetmessageid: <>
2014-07-17 15:13:38gvanrossumlinkissue21645 messages
2014-07-17 15:13:38gvanrossumcreate