This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients bkabrda, neologix, njs, vstinner
Date 2017-03-22.08:15:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwanANEbOL7Or7HUctCg9ax_GcKx-S_Gbj2ADna7Vx1a4w@mail.gmail.com>
In-reply-to <1490153868.39.0.143397446312.issue21895@psf.upfronthosting.co.za>
Content
Nathaniel Smith added the comment:
> In any case, the issue here remains that one shouldn't have to use set_wakeup_fd for a signal to interrupt time.sleep etc.

CPython implements a C signal handler which sets a flag and then exits
immediately. The thread getting the signal will probably interrupts
the current blocking syscall with EINTR. CPython detects that a signal
flag was set, calls the *Python* signal handler. If the Python signal
handler raises an exception, the syscall is abandonned. Otherwise, the
syscall is restarted.

So "interrupting sleep" is only reliable if:

* there is only one thread (the "main" thread)
* the syscall is interrupted with EINTR
* the signal handler raises an exception

When you implement an event loop, raising an exception may be the best
design. In asyncio, the Python signal handler calls loop.call_soon()
to execute the final callback (3rd signal handler of the same
signal!). The rule in asynico is not call blocking syscalls, or at
least ensure that they don't block too long (ex: use aiofiles to
access the filesystem).
History
Date User Action Args
2017-03-22 08:15:39vstinnersetrecipients: + vstinner, njs, neologix, bkabrda
2017-03-22 08:15:39vstinnerlinkissue21895 messages
2017-03-22 08:15:39vstinnercreate