Charles-François Natali added the comment: > The patch is fine, but it is hard to rely on it to prevent bugs from > happening because that requires cooperation from all modules registering > signal handlers.
Once again, that's why the bug report says "*limit* EINTR occurrences". We all know this won't prevent all occurrences. > Anyway it facilitates reusing code that was not written for an event-driven > context (and many will do that through .run_in_executor()). If the patch is > accepted, it would be wise to write a note in .run_in_executor()'s doc saying > that asyncio uses SA_RESTART by default in all its handler and that EINTR is > prevented *as long as* no other handlers are registered elsewhere. The single most common cause of signals is SIGCHLD (in a "normal" code). Since asyncio setups up the SIGCHLD handler, this should cover most of the cases (BTW, just set up a SIGCHLD handler in any Python process spawning subprocesses, and it becomes unusable since EINTR isn't handled in the stdlib). > Please answer this question. Under what circumstances can a signal handler > interrupt a blocking system call in a thread that is not the main thread? I answered in my prevous message: POSIX makes no guarantee whatsoever as to which thread will receive the signal (except of course in case of synchronous signales like SIGSEGV/SIGFPE). The Linux kernel makes it best to deliver it to the main thread when possible, but in certains cases it can't, and other OS just don't bother. See e.g. issue #19857 for an occurrence on FreeBSD. Also, even the main thread can sometimes make blocking calls subject to EINTR (e.g. acquiring a lock). So the possibility of breakage are real, but if people prefer to wait & see, that's fine :-) ---------- _______________________________________ 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