[issue9867] Interrupted system calls are not retried

Changes by Antoine Pitrou : -- resolution: out of date -> duplicate superseder: -> file readline, readlines & readall methods can lose data on EINTR versions: -Python 3.2, Python 3.3 ___ Python tracker __

[issue9867] Interrupted system calls are not retried

Antoine Pitrou added the comment: This has been fixed in issue #10956 (Python 3 and the io module) and issue #12268 (Python 2's file objects). -- components: +Interpreter Core resolution: -> out of date status: open -> closed versions: -Python 3.1 ___

[issue9867] Interrupted system calls are not retried

Changes by Daniel Neuhäuser : -- nosy: +DasIch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9867] Interrupted system calls are not retried

Ronald Oussoren added the comment: On 16 Sep, 2010, at 15:40, Armin Ronacher wrote: > > Armin Ronacher added the comment: > >> You conveniently didn't quote the part of my message where I explained >> why I think there may be a problem. > I understand that, but there are already cases in Py

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: > You conveniently didn't quote the part of my message where I explained > why I think there may be a problem. I understand that, but there are already cases in Python where EINTR is handled properly. In fact, quoting socketmodule.c: if (res == EINTR &&

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: > setting the SA_RESTART in the call to sigaction should work (on OSX > HAVE_SIGACTION is defined), unless the manpage is lying. It should work, haven't tried. From what I understand on a BSD system, retrying is the default. -- versions: +Python 3.3

[issue9867] Interrupted system calls are not retried

Antoine Pitrou added the comment: > Because Python's signal handlers only set a flag and do the actual > action later on blindly rerunning system calls when errno == EINTR may > result in programs that don't seem to react to signals at all. You just need to call PyErr_CheckSignals() and check i

[issue9867] Interrupted system calls are not retried

Ronald Oussoren added the comment: On 16 Sep, 2010, at 14:38, Armin Ronacher wrote: > > Armin Ronacher added the comment: > > There is a funny story related to that though :) > > "BSD avoids EINTR entirely and provides a more convenient approach: > to restart the interrupted primitive, inst

[issue9867] Interrupted system calls are not retried

Ronald Oussoren added the comment: On 16 Sep, 2010, at 14:36, Armin Ronacher wrote: > > Armin Ronacher added the comment: > >> Wouldn't retrying on EINTR cause havoc when you try to interrupt a process? > > All your C applications are doing it, why should Python cause havok there? > Check

[issue9867] Interrupted system calls are not retried

Changes by Andreas Stührk : -- nosy: +Trundle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue9867] Interrupted system calls are not retried

Antoine Pitrou added the comment: Some parts of the stdlib already retry manually (such as SocketIO, subprocess, multiprocessing, socket.sendall), so it doesn't sound unreasonable for the IO lib to retry too. There are/were other people complaining in similar cases: #7978, #1628205.

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: There is a funny story related to that though :) "BSD avoids EINTR entirely and provides a more convenient approach: to restart the interrupted primitive, instead of making it fail." BSD does, but the Mach/XNU kernel combo on OS X is not. Which is why all th

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: > Wouldn't retrying on EINTR cause havoc when you try to interrupt a process? All your C applications are doing it, why should Python cause havok there? Check the POSIX specification on that if you don't trust me. > That is: what would happen with the propos

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: The following minimal C code shows how EINTR can be handled: #include #include #include #include #define BUFFER_SIZE 1024 int main() { char buffer[BUFFER_SIZE]; printf("PID = %d\n", getpid()); while (1) { int rv = fgetc(stdin);

[issue9867] Interrupted system calls are not retried

Ronald Oussoren added the comment: Wouldn't retrying on EINTR cause havoc when you try to interrupt a process? That is: what would happen with the proposed patch when a python script does a read that takes a very long time and the user tries to interrupt the script (by using Ctrl+C to send a

[issue9867] Interrupted system calls are not retried

Martin v. Löwis added the comment: Am 16.09.10 14:06, schrieb Armin Ronacher: > > Armin Ronacher added the comment: > >> Hmm. So under what conditions should it continue, and under what >> conditions should it raise an exception (when errno is EINTR)? > > EINTR indicates a temporary failure. I

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: > Hmm. So under what conditions should it continue, and under what > conditions should it raise an exception (when errno is EINTR)? EINTR indicates a temporary failure. In that case it should always retry. A common macro for handling that might look like thi

[issue9867] Interrupted system calls are not retried

Martin v. Löwis added the comment: > One could argue of course that every user of Python should handle > EINTR, but that's something I think should be solved in the IO > library because very few people know that one is supposed to restart > syscalls on EINTR on POSIX systems. > > Ruby for instan

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: Interestingly even PHP handles that properly. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue9867] Interrupted system calls are not retried

Armin Ronacher added the comment: One could argue of course that every user of Python should handle EINTR, but that's something I think should be solved in the IO library because very few people know that one is supposed to restart syscalls on EINTR on POSIX systems. Ruby for instance handles

[issue9867] Interrupted system calls are not retried

Martin v. Löwis added the comment: I fail to see why this is a bug. If the system call is interrupted, why should Python not report that? -- nosy: +loewis ___ Python tracker ___

[issue9867] Interrupted system calls are not retried

Changes by Armin Ronacher : -- versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue9867] Interrupted system calls are not retried

Ned Deily added the comment: The test fails exactly the same way using a python 2.6.6 on a current Debian (testing) Linux 2.6.32 so I think it better to remove the OS X from the title. Also the versions field refers to where a potential fix might be applied; that rules out 2.5 and 2.6 since

[issue9867] Interrupted system calls are not retried on OS X

New submission from Armin Ronacher : Currently Python does not check fread and other IO calls for EINTR. This usually is not an issue, but on OS X a continued program will be sent an SIGCONT signal which causes fread to be interrupted. Testcase: mitsuh...@nausicaa:~$ python2.7 Python 2.7 (r2