Victor: read(2) and recv(2) are defined as returning all available data when interrupted by a signal and might therefore not return an error. The same is true for write(2): it returns the number of bytes written when there are any bytes written (instead of setting errno to SIGINT and returning an error).

I'd expect the C implementation of readall to behave the same as the Python implementation: a signal handler that raises an exception can cause data loss due to discarding the buffer that's used to collect the data.  The data loss in the script isn't worse than it currently is, AFAIK it would currently lose data due to raising the exception just after the call to readall in the next loop through the eval loop.

If I read the issue correctly the signal handling issue mentioned here is basically similar to the one in this scriptlet:

# BEGIN
import signal, sys
import subprocess

def handler(sig, frames):
    raise RuntimeError("Alarm!")

signal.signal(signal.SIGALRM, handler)
signal.alarm(5)
b = sys.stdin.buffer.raw.readall()
print(len(b))
signal.alarm(0)
#END

When you run this with a large file on stdin (I've used /dev/zero) the script will continue to run indefinitely and cannot be cleanly interrupted at all (on my system its eventually killed by the system due to running out of its rlimit limitations, otherwise it can only be killed by sending it an uncatchable signal like SIGKILL or SIGABRT).