> 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 :-)