STINNER Victor added the comment:
Last time I had to make a major change related to signal handling, it was in
the asyncio module because of a race conditon which occurred on FreeBSD.
commit fe5649c7b7bf52147480d6b1124a3d8e3597aee3
Author: Victor Stinner <victor.stin...@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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30038>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
