[issue18885] handle EINTR in the stdlib

STINNER Victor added the comment: > With PEP 475 now implemented (see Issue 23648), perhaps this could be closed? > Or is there something else to be done? Yes, this issue was fully fixed by the implementation of the PEP 475 in Python 3.5. -- resolution: -> fixed status: open -> close

[issue18885] handle EINTR in the stdlib

Martin Panter added the comment: With PEP 475 now implemented (see Issue 23648), perhaps this could be closed? Or is there something else to be done? -- ___ Python tracker ___ _

[issue18885] handle EINTR in the stdlib

Martin Panter added the comment: See also Issue 23285 for the PEP -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue18885] handle EINTR in the stdlib

Changes by Martin Panter : -- nosy: +vadmium ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue18885] handle EINTR in the stdlib

STINNER Victor added the comment: FYI Charles-François and me are working on a PEP to address this issue: the PEP 475. The PEP is not ready yet for a review. -- ___ Python tracker _

[issue18885] handle EINTR in the stdlib

Changes by Piotr Dobrogost : -- nosy: +piotr.dobrogost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue18885] handle EINTR in the stdlib

Changes by Yongzhi Pan : -- nosy: +fossilet ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue18885] handle EINTR in the stdlib

Changes by STINNER Victor : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue18885] handle EINTR in the stdlib

Larry Hastings added the comment: I don't want this checked in to 3.4. (Congratulations, this is my first "no" as a release manager!) -- ___ Python tracker ___ _

[issue18885] handle EINTR in the stdlib

Antoine Pitrou added the comment: > I do not consider this a feature; that EINTR is exposed as an > exception from the API is a bug. select() currently works as specified; you are proposing a compatibility-breaking change to the API, not a bugfix. We're left with the fact that the API is inconv

[issue18885] handle EINTR in the stdlib

Gregory P. Smith added the comment: I do not consider this a feature; that EINTR is exposed as an exception from the API is a bug. But Larry is the only one who can actually make that decision as the 3.4 release manager (+nosy'd). > by returning an empty list you force the user to handle EINT

[issue18885] handle EINTR in the stdlib

Antoine Pitrou added the comment: > I know that returning an empty list changes the semantics: I just > think that's better - or not as bad - than the current possibility of > having any single piece of code possibly die upon EINTR. > > If you want to implement retry with timeout re-computation,

[issue18885] handle EINTR in the stdlib

Charles-François Natali added the comment: > Well this is wishing thinking, since by returning an empty list you > force the user to handle EINTR - just in a different way. I know that returning an empty list changes the semantics: I just think that's better - or not as bad - than the current po

[issue18885] handle EINTR in the stdlib

Antoine Pitrou added the comment: On dim., 2013-12-01 at 08:14 +, Charles-François Natali wrote: > So really, I'm like Gregory: I don't care which solution we chose, but > I just don't want to have to let the user handle EINTR. Well this is wishing thinking, since by returning an empty list

[issue18885] handle EINTR in the stdlib

Antoine Pitrou added the comment: > Guido's point was that it is already a bug in code to not check the elapsed > time after a select call returns rather than assuming the full timeout time > has elapsed. I don't understand how it's a bug. You're assuming select() has unreliable timing, but it d

[issue18885] handle EINTR in the stdlib

Charles-François Natali added the comment: Just for the record, I was initially in favor of recomputing the timeout and retrying upon EINTR, but Guido prefers to return empty lists, and since that's a better compromise than the current situation (I've seen *many* people complaining on EINTR poppi

[issue18885] handle EINTR in the stdlib

Gregory P. Smith added the comment: Guido's point was that it is already a bug in code to not check the elapsed time after a select call returns rather than assuming the full timeout time has elapsed. Correct code today already needs to deal with both situations (OSError(EINTR) and select returni

[issue18885] handle EINTR in the stdlib

Armin Rigo added the comment: Modules/socketmodule.c is using a simple style to implement socket timeouts using select(). If I were to naively copy this style over to pure Python, it would work in current Pythons; I'd get occasionally an OSError(EINTR), which I would have presumably been anno

[issue18885] handle EINTR in the stdlib

Guido van Rossum added the comment: We went through this whole discussion before. Returning immediately with three empty lists is better than raising InterruptedError. Retrying is not always better. -- ___ Python tracker

[issue18885] handle EINTR in the stdlib

Gregory P. Smith added the comment: > I've always had an implicit understanding that calls with timeouts may, for > whatever reason, return sooner than requested (or later!), and the most > careful approach is to re-check the clock again. exactly. at the system call level you can be interrupt

[issue18885] handle EINTR in the stdlib

Antoine Pitrou added the comment: > > I've always had an implicit understanding that calls with timeouts may, > > for whatever reason, return sooner than requested (or later!), and the > > most careful approach is to re-check the clock again. > > I've always had the implicit understanding that i

[issue18885] handle EINTR in the stdlib

Richard Oudkerk added the comment: > I've always had an implicit understanding that calls with timeouts may, > for whatever reason, return sooner than requested (or later!), and the > most careful approach is to re-check the clock again. I've always had the implicit understanding that if I use a

[issue18885] handle EINTR in the stdlib

Guido van Rossum added the comment: I wouldn't call that "being the most careful". I've always had an implicit understanding that calls with timeouts may, for whatever reason, return sooner than requested (or later!), and the most careful approach is to re-check the clock again. --

[issue18885] handle EINTR in the stdlib

Armin Rigo added the comment: Am I correct in thinking that you're simply replacing the OSError(EINTR) with returning empty lists? This is bound to subtly break code, e.g. the code that expects reasonably that a return value of three empty lists means the timeout really ran out (i.e. the vers

[issue18885] handle EINTR in the stdlib

Changes by koobs : -- nosy: +koobs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mail

[issue18885] handle EINTR in the stdlib

Charles-François Natali added the comment: Alright, here's a first step: select/poll/epoll/etc now return empty lists/tuples upon EINTR. This comes with tests (note that all those tests could probably be factored, but that's another story). -- keywords: +needs review, patch stage: needs

[issue18885] handle EINTR in the stdlib

Charles-François Natali added the comment: (replying to Guido's post in another thread) > Charles-Francois, sorry to add you back to the bug, but (a) I thought you had > agreed to a compromise patch that restarts signals in most cases but not for > select(), poll() etc.; (b) I may have found a

[issue18885] handle EINTR in the stdlib

Changes by Armin Rigo : -- nosy: +arigo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue18885] handle EINTR in the stdlib

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue18885] handle EINTR in the stdlib

Gregory P. Smith added the comment: I wrote too many words. In short: time.sleep()'s behavior should remain as it is today given how it is documented to behave. If you disagree, consider adding an optional interruptable=False parameter so that both behavior options exist. ALL IO calls and w

[issue18885] handle EINTR in the stdlib

Guido van Rossum added the comment: On Sat, Aug 31, 2013 at 9:56 AM, Charles-François Natali wrote: > > Charles-François Natali added the comment: > > Gregory, thanks, that's what I was planning to do. > > But since the recent discussions (mainly on selectors), there are points I > obviously do

[issue18885] handle EINTR in the stdlib

Antoine Pitrou added the comment: > FWIW, there are times when we *want* the interrupted system call to > return control to Python rather than retrying the call. I'm a bit curious, do you know of any use cases? > If someone is making a Python equivalent of the low level system call > such as se

[issue18885] handle EINTR in the stdlib

Changes by Charles-François Natali : -- nosy: -neologix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue18885] handle EINTR in the stdlib

Charles-François Natali added the comment: Gregory, thanks, that's what I was planning to do. But since the recent discussions (mainly on selectors), there are points I obviously don't - and won't - agree with (such as select() returning EINTR or returning early, same for sleep()), I'm not int

[issue18885] handle EINTR in the stdlib

Changes by Guido van Rossum : -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue18885] handle EINTR in the stdlib

Gregory P. Smith added the comment: FYI - use the changes made in http://bugs.python.org/issue12268 as a guide for how to deal with EINTR properly at the C level. See the _PyIO_trap_eintr() function for example. See also _eintr_retry_call() in Lib/subprocess.py. FWIW, there are times when we

[issue18885] handle EINTR in the stdlib

Changes by Charles-François Natali : -- nosy: +haypo, pitrou, sbt ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue18885] handle EINTR in the stdlib

New submission from Charles-François Natali: As discussed in http://mail.python.org/pipermail/python-dev/2013-August/128204.html, I think that we shouldn't let EINTR leak to Python code: it should be handled properly by the C code, so that users (and the Python part of the stdlib) don't have t