Message333768
In short, attached PR reverts the following commit:
commit fe5649c7b7bf52147480d6b1124a3d8e3597aee3
Author: Victor Stinner <victor.stinner@gmail.com>
Date: Thu Jul 17 22:43:40 2014 +0200
Python issue #21645, Tulip issue 192: Rewrite signal handling
Since Python 3.3, the C signal handler writes the signal number into the wakeup
file descriptor and then schedules the Python call using Py_AddPendingCall().
asyncio uses the wakeup file descriptor to wake up the event loop, and relies
on Py_AddPendingCall() to schedule the final callback with call_soon().
If the C signal handler is called in a thread different than the thread of the
event loop, the loop is awaken but Py_AddPendingCall() was not called yet. In
this case, the event loop has nothing to do and go to sleep again.
Py_AddPendingCall() is called while the event loop is sleeping again and so the
final callback is not scheduled immediatly.
This patch changes how asyncio handles signals. Instead of relying on
Py_AddPendingCall() and the wakeup file descriptor, asyncio now only relies on
the wakeup file descriptor. asyncio reads signal numbers from the wakeup file
descriptor to call its signal handler.
=> https://github.com/python/asyncio/issues/192
Since this change, the C signal handler of Python has been reworked in bpo-30038 by:
commit 4ae01496971624c75080431806ed1c08e00f22c7
Author: Nathaniel J. Smith <njs@pobox.com>
Date: Tue May 16 14:12:11 2017 -0700
bpo-30038: fix race condition in signal delivery + wakeup fd (#1082)
Before, it was possible to get the following sequence of
events (especially on Windows, where the C-level signal handler for
SIGINT is run in a separate thread):
- SIGINT arrives
- trip_signal is called
- trip_signal writes to the wakeup fd
- the main thread wakes up from select()-or-equivalent
- the main thread checks for pending signals, but doesn't see any
- the main thread drains the wakeup fd
- the main thread goes back to sleep
- trip_signal sets is_tripped=1 and calls Py_AddPendingCall to notify
the main thread the it should run the Python-level signal handler
- the main thread doesn't notice because it's asleep
This has been causing repeated failures in the Trio test suite:
https://github.com/python-trio/trio/issues/119
I am very scared by signals. These things are very complex and it's hard to handle them proplery on all platforms :-( So I'm not excited by changing the code.
> If the pipe is full OSError is raised.
Are you able to reproduce this issue, or is it a theorical issue?
What is the pipe buffer size on Linux? See bpo-33733. |
|
Date |
User |
Action |
Args |
2019-01-16 14:14:17 | vstinner | set | recipients:
+ vstinner, njs, asvetlov, yselivanov |
2019-01-16 14:14:16 | vstinner | set | messageid: <1547648056.41.0.0894588769305.issue35749@roundup.psfhosted.org> |
2019-01-16 14:14:16 | vstinner | link | issue35749 messages |
2019-01-16 14:14:16 | vstinner | create | |
|