Ronald Oussoren added the comment:
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).
----------
nosy: +ronaldoussoren
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9504>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
