Charles-François Natali added the comment:
> Guido van Rossum added the comment:
>
> That's just rhetoric -- I am beginning to believe that nobody has any data.
> Here's some opposite rhetoric. If it ain't broke, don't fix it. Plus, if
> it's so much better, why isn't it the default? If you say "for backward
> compatibility" I will say "exactly!"
Well, it's the default on BSD and Linux, but Python deliberately disables it:
"""
PyOS_setsig(int sig, PyOS_sighandler_t handler)
{
#ifdef HAVE_SIGACTION
/* Some code in Modules/signalmodule.c depends on sigaction() being
* used here if HAVE_SIGACTION is defined. Fix that if this code
* changes to invalidate that assumption.
*/
struct sigaction context, ocontext;
context.sa_handler = handler;
sigemptyset(&context.sa_mask);
context.sa_flags = 0;
if (sigaction(sig, &context, &ocontext) == -1)
return SIG_ERR;
return ocontext.sa_handler;
#else
PyOS_sighandler_t oldhandler;
oldhandler = signal(sig, handler);
#ifdef HAVE_SIGINTERRUPT
siginterrupt(sig, 1);
#endif
return oldhandler;
#endif
}
"""
It's done because we want syscalls to return with EINTR to be able to
run signal handlers, but since asyncio uses a wakeup file descriptor,
it's unnecessary here.
> Any *other* I/O syscalls (unless a program violates the asyncio rules against
> doing your own blocking I/O) would either be disk file I/O, which IIUC cannot
> elicit EINTR, or run in a separate thread, where presumably it wouldn't be
> interrupted by a signal handler, since SIGCHLD is delivered to the main
> thread.
> (It's actually the last part I am not 100% sure of.)
In order:
- Linux avoids EINTR on file I/O, but that's not necessarily the case
on other OS (e.g. on NFS)
- Many syscalls can return EINTR, not only I/O related, e.g. waitpid().
- As for threads, there's absolutely no guarantee that the signal will
be delivered to the main thread.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue19850>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
