STINNER Victor <vstin...@redhat.com> added the comment:

In short, attached PR reverts the following commit:

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.

=> 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 <n...@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.

----------
nosy: +njs, vstinner
title: Ignore exception if event loop wakeup pipe is full -> Rewrite asyncio 
signal handler

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue35749>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to