Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

In article , Victor Stinner wrote: >2014-09-02 23:03 GMT+02:00 Matthew Woodcraft : >> In any case I think PEP 475 should be explaining what is going to happen >> to signal.siginterrupt(). Will setting flag=True be supported? > I first proposed to deprecate the function, but Charles-François > t

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-02 23:03 GMT+02:00 Matthew Woodcraft : > In any case I think PEP 475 should be explaining what is going to happen > to signal.siginterrupt(). Will setting flag=True be supported? I first proposed to deprecate the function, but Charles-François thinks that it's unrelated to the PEP (it can

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-02 23:02 GMT+02:00 Matthew Woodcraft : > I think people who use sleep() in their programs could benefit from not > having to worry about EINTR as much as anyone else. The behaviour of time.sleep() is worse than what I expected. On UNIX, if select() fails with EINTR, time.sleep() calls PyE

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Antoine Pitrou wrote: >Matthew Woodcraft wrote: >> (The program handles SIGTERM so that it can do a bit of cleanup before >> exiting, and it uses the signal-handler-sets-a-flag technique. The call >> that might be interrupted is sleep(), so the program doesn't strictly >> _rely_ on the existing

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Nick Coghlan wrote: >On 2 September 2014 07:17, Matthew Woodcraft wrote: >> (The program handles SIGTERM so that it can do a bit of cleanup before >> exiting, and it uses the signal-handler-sets-a-flag technique. The call >> that might be interrupted is sleep(), so the program doesn't strictly >

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 1 Sep 2014 21:17:33 + (UTC) Matthew Woodcraft wrote: > > > If such applications exist, they are not portable and are subject to > > race conditions (deadlock if the signal comes before the system call). > > The program is certainly not portable (which is not any kind of a > problem),

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On 2 September 2014 07:17, Matthew Woodcraft wrote: > > (The program handles SIGTERM so that it can do a bit of cleanup before > exiting, and it uses the signal-handler-sets-a-flag technique. The call > that might be interrupted is sleep(), so the program doesn't strictly > _rely_ on the existing

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner wrote: > HTML version: > http://legacy.python.org/dev/peps/pep-0475/ > PEP: 475 > Title: Retry system calls failing with EINTR I think the proposed design for how Python should behave is a good one. But I think this proposal needs to be treated in the same way as any other backw

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

"R. David Murray" : > On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa wrote: >> * Allow the application to react to signals immediately in the main >>flow. > > You don't want to be writing your code in Python then. In Python you > *never* get to react immediately to signals. The interpret

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

"R. David Murray" : > Windows. Enough said? > [...] > This should tell you just about everything you need to know about why > we want to fix this problem so that things work cross platform. I feel your pain. Well, not really; I just don't want my linux bliss to be taken away. Marko ___

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 11:47:07 -0400 "R. David Murray" wrote: > > > > The two requirements are: > > > > * Allow the application to react to signals immediately in the main > >flow. > > You don't want to be writing your code in Python then. In Python > you *never* get to react immediately to

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa wrote: > Charles-François Natali : > > >> Which raises an interesting question: what happens to the os.read() > >> return value if SIGINT is received? > > > > There's no return value, a KeywordInterrupt exception is raised. > > The PEP wouldn't

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 08:30:27 +0300, Marko Rauhamaa wrote: > "R. David Murray" : > > > PS: I recently switched from using selectors to using a timeout on a > > socket because in that particular application I could, and because > > reading a socket with a timeout handles EINTR (in recent python > >

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Hi, I'm +1 on the whole PEP. > Writing a signal handler is difficult, only "async-signal safe" > functions can be called. You mean a C signal handler? Python signal handlers are not restricted. > Some signals are not interesting and should not interrupt the the > application. There are two op

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 19:15:33 +1200 Greg Ewing wrote: > Victor Stinner wrote: > > > > Le 1 sept. 2014 00:17, "Marko Rauhamaa" > > a écrit : > > > If a signal is received when read() or write() has completed its task > > > partially (> 0 bytes), no EINTR is returned but

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

2014-09-01 12:15 GMT+01:00 Marko Rauhamaa : > Charles-François Natali : > >>> Which raises an interesting question: what happens to the os.read() >>> return value if SIGINT is received? >> >> There's no return value, a KeywordInterrupt exception is raised. >> The PEP wouldn't change this behavior.

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Charles-François Natali : >> Which raises an interesting question: what happens to the os.read() >> return value if SIGINT is received? > > There's no return value, a KeywordInterrupt exception is raised. > The PEP wouldn't change this behavior. Slightly disconcerting... but I'm sure overriding S

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

There's no return value, a KeywordInterrupt exception is raised. The PEP wouldn't change this behavior. As for the general behavior: all programming languages/platforms handle EINTR transparently. It's high time for Python to have a sensible behavior in this regard. 2014-09-01 8:38 GMT+01:00 Ma

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner : > No, it's the opposite. The PEP doesn't change the default behaviour of > SIGINT: CTRL+C always interrupt the program. Which raises an interesting question: what happens to the os.read() return value if SIGINT is received? Marko ___

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Le 1 sept. 2014 02:40, "Greg Ewing" a écrit : > > Victor Stinner wrote: >> >> As written in the PEP, if you want to be notified of the signal, set a signal handler which raises an exception. > > > I'm not convinced that this covers all possible use cases. > It might be all right if you have contro

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

No, it's the opposite. The PEP doesn't change the default behaviour of SIGINT: CTRL+C always interrupt the program. Victor Le 1 sept. 2014 08:12, "Paul Moore" a écrit : > On 31 August 2014 22:38, Victor Stinner wrote: > > This case is described as the use case #2 in the PEP, so it is > supporte

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner wrote: Le 1 sept. 2014 00:17, "Marko Rauhamaa" > a écrit : > If a signal is received when read() or write() has completed its task > partially (> 0 bytes), no EINTR is returned but the partial count. > Obviously, Python should take that possibility int

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On 31 August 2014 22:38, Victor Stinner wrote: > This case is described as the use case #2 in the PEP, so it is supported. As > written in the PEP, if you want to be notified of the signal, set a signal > handler which raises an exception. For example the default signal handler > for SIGINT raises

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

"R. David Murray" : > PS: I recently switched from using selectors to using a timeout on a > socket because in that particular application I could, and because > reading a socket with a timeout handles EINTR (in recent python > versions), whereas reading a non-blocking socket doesn't. Under the >

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Sun, 31 Aug 2014 20:14:50 -0700, Dan Stromberg wrote: > On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing > wrote: > > Victor Stinner wrote: > >> > >> As written in the PEP, if you want to be notified of the signal, set a > >> signal handler which raises an exception. > > > > I'm not convinced that

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing wrote: > Victor Stinner wrote: >> >> As written in the PEP, if you want to be notified of the signal, set a >> signal handler which raises an exception. > > I'm not convinced that this covers all possible use cases. > It might be all right if you have co

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner wrote: As written in the PEP, if you want to be notified of the signal, set a signal handler which raises an exception. I'm not convinced that this covers all possible use cases. It might be all right if you have control over the signal handler, but what if you don't? I think it

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Le 1 sept. 2014 00:17, "Marko Rauhamaa" a écrit : > If a signal is received when read() or write() has completed its task > partially (> 0 bytes), no EINTR is returned but the partial count. > Obviously, Python should take that possibility into account so that > raising an exception in the signal

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On Mon, 01 Sep 2014 01:15:12 +0300 Marko Rauhamaa wrote: > > If a signal is received when read() or write() has completed its task > partially (> 0 bytes), no EINTR is returned but the partial count. > Obviously, Python should take that possibility into account so that > raising an exception in t

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Le 1 sept. 2014 00:04, "Marko Rauhamaa" a écrit : > > Victor Stinner : > > > But I don't get you point. How does this PEP make the situation worse? > > Did I say it would? I just wanted to make sure the system call > resumption doesn't become mandatory. The syscall is only retried on EINTR if the

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Ethan Furman : > On 08/31/2014 02:19 PM, Marko Rauhamaa wrote: >> The application will often want the EINTR return (exception) instead >> of having the function resume on its own. > > Examples? > > As an ignorant person in this area, I do not know why I would ever > want to have EINTR raised inste

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner : > But I don't get you point. How does this PEP make the situation worse? Did I say it would? I just wanted to make sure the system call resumption doesn't become mandatory. Haven't thought through what the exception raising technique would entail. It might be perfectly ok apart

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Le dimanche 31 août 2014, Marko Rauhamaa a écrit : > Victor Stinner >: > > > Sorry but I don't understand your remark. What is your problem with > > retrying syscall on EINTR? > > The application will often want the EINTR return (exception) instead of > having the function resume on its own. Th

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

On 08/31/2014 02:19 PM, Marko Rauhamaa wrote: Victor Stinner : Sorry but I don't understand your remark. What is your problem with retrying syscall on EINTR? The application will often want the EINTR return (exception) instead of having the function resume on its own. Examples? As an ignor

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner : > Sorry but I don't understand your remark. What is your problem with > retrying syscall on EINTR? The application will often want the EINTR return (exception) instead of having the function resume on its own. > Can you please elaborate? What do you mean by "get wrong"? Proper

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Hi, Sorry but I don't understand your remark. What is your problem with retrying syscall on EINTR? Can you please elaborate? What do you mean by "get wrong"? Victor Le dimanche 31 août 2014, Marko Rauhamaa a écrit : > Victor Stinner >: > > > Proposition > > === > > > > If a system call

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner : > Proposition > === > > If a system call fails with ``EINTR``, Python must call signal > handlers: call ``PyErr_CheckSignals()``. If a signal handler raises > an exception, the Python function fails with the exception. > Otherwise, the system call is retried. If the syste