> 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.