Charles-François Natali added the comment: > I may be missing something here but isn't the whole point of EINTR to > interrupt a potentially long running syscall?
No. EINTR is an artifact of the early Unix design, because failing when a signal was delivered was simpler than restarting the syscall. Nowadays, most syscalls are restarted by default (that's was true on BSD, and nowadays Linux also follows this trend). See e.g. http://lkml.indiana.edu/hypermail/linux/kernel/0104.0/0743.html and http://man7.org/linux/man-pages/man7/signal.7.html One reason why EINTR can occur so often in CPython is because we set up signal handlers without SA_RESTART (which is set by default by signal(3)). The reason is likely that we want the syscall to return to be able to call PyCheckSignals() (since we cannot run Python code from a signal handler). But since in this case, PyCheckSignals() is called anyway from the main eval loop, signal handlers will still be run in a timely manner (and as noted, the proper way to handle signals is to use a wakeup file descriptor which can be used by select()). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16853> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
