Message291474
| Author | vstinner |
|---|
| Recipients | njs, vstinner |
|---|
| Date | 2017-04-11.10:20:12 |
|---|
| SpamBayes Score | -1.0 |
|---|
| Marked as misclassified | Yes |
|---|
| Message-id | <1491906013.12.0.848290814997.issue30038@psf.upfronthosting.co.za> |
|---|
| In-reply-to | |
|---|
| Content |
|---|
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.commitfe5649c7b7bf52147480d6b1124a3d8e3597aee3Author: 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. |
| History |
|---|
| Date | User | Action | Args |
|---|
| 2017-04-11 10:20:13 | vstinner | set | recipients: +vstinner,njs | | 2017-04-11 10:20:13 | vstinner | set | messageid: <1491906013.12.0.848290814997.issue30038@psf.upfronthosting.co.za> | | 2017-04-11 10:20:13 | vstinner | link | issue30038 messages | | 2017-04-11 10:20:12 | vstinner | create | |
|