STINNER Victor added the comment: > The intention if the code was that the Py_AddPendingCall() would complete > before the thread switch.
In fact I also expected Py_AddPendingCall() to be called *before* writing the signal number into the "wakeup fd". I guess that before nobody was relying on the "wakeup fd" *and* and the callback. > 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. It doesn't work for Tulip which targets Python 3.3. Oh... I just saw that Python 2.7 calls Py_AddPendingCall() and *then* writes "\0" into wakeup fd... So Python 2.7 does not have the issue! But yes, we may change the C signal handler in Python 3.5 because it makes more sense to call Py_AddPendingCall() to avoid this specific race condition. > I think your patch to Tulip is fine. Good :) I will test it on FreeBSD. If it fixes the issue, I will apply it. We will see if it makes all buildbots happy. > I wouldn't worry about missing a signal when things are busy -- AFAIK the > child process reaper will reap multiple processes. Well, Py_AddPendingCall() also has a limit which is smaller and it does *not* warn when signals are dropped :-( -- I don't know if it can be useful, but there is also the signal.pthread_sigmask() which can be used to "queue" pending signals. Unblocking signals will flush the queue. It might help to mitigate burst of signals in a short window.... I don't know if signal.pthread_sigmask() has a longer queue than Python. And it may be tricky to decide when and where the signals should be blocked and unblocked. If a signal is blocked and the process gets the signal more than once, the signal is only raised once when the signal is unblocked. I don't know if it is an issue or not if asyncio only calls the signal handler once in this case. ---------- _______________________________________ 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
