In article CAMpsgwabYhXB0OG3UhdX=fucyonajgzpwd-g8stdaukjzpj...@mail.gmail.com,
Victor Stinner victor.stin...@gmail.com wrote:
2014-09-02 23:03 GMT+02:00 Matthew Woodcraft matt...@woodcraft.me.uk:
In any case I think PEP 475 should be explaining what is going to happen
to signal.siginterrupt().
On 2 September 2014 07:17, Matthew Woodcraft matt...@woodcraft.me.uk 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
On Mon, 1 Sep 2014 21:17:33 + (UTC)
Matthew Woodcraft matt...@woodcraft.me.uk 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
Nick Coghlan ncogh...@gmail.com wrote:
On 2 September 2014 07:17, Matthew Woodcraft matt...@woodcraft.me.uk 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
Antoine Pitrou solip...@pitrou.net wrote:
Matthew Woodcraft matt...@woodcraft.me.uk 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
2014-09-02 23:02 GMT+02:00 Matthew Woodcraft matt...@woodcraft.me.uk:
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,
2014-09-02 23:03 GMT+02:00 Matthew Woodcraft matt...@woodcraft.me.uk:
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
On 31 August 2014 22:38, Victor Stinner victor.stin...@gmail.com 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
Victor Stinner wrote:
Le 1 sept. 2014 00:17, Marko Rauhamaa ma...@pacujo.net
mailto:ma...@pacujo.net 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
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 p.f.mo...@gmail.com a écrit :
On 31 August 2014 22:38, Victor Stinner victor.stin...@gmail.com wrote:
This case is described as the use
Le 1 sept. 2014 02:40, Greg Ewing greg.ew...@canterbury.ac.nz 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
Victor Stinner victor.stin...@gmail.com:
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
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
Charles-François Natali cf.nat...@gmail.com:
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
2014-09-01 12:15 GMT+01:00 Marko Rauhamaa ma...@pacujo.net:
Charles-François Natali cf.nat...@gmail.com:
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
On Mon, 01 Sep 2014 19:15:33 +1200
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Victor Stinner wrote:
Le 1 sept. 2014 00:17, Marko Rauhamaa ma...@pacujo.net
mailto:ma...@pacujo.net a écrit :
If a signal is received when read() or write() has completed its task
partially ( 0
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 options
On Mon, 01 Sep 2014 08:30:27 +0300, Marko Rauhamaa ma...@pacujo.net wrote:
R. David Murray rdmur...@bitdance.com:
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
On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa ma...@pacujo.net wrote:
Charles-François Natali cf.nat...@gmail.com:
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
On Mon, 01 Sep 2014 11:47:07 -0400
R. David Murray rdmur...@bitdance.com 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
R. David Murray rdmur...@bitdance.com:
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.
R. David Murray rdmur...@bitdance.com:
On Mon, 01 Sep 2014 14:15:52 +0300, Marko Rauhamaa ma...@pacujo.net 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
Victor Stinner victor.stin...@gmail.com 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
HTML version:
http://legacy.python.org/dev/peps/pep-0475/
PEP: 475
Title: Retry system calls failing with EINTR
Version: $Revision$
Last-Modified: $Date$
Author: Charles-François Natali cf.nat...@gmail.com, Victor Stinner
victor.stin...@gmail.com
Status: Draft
Type: Standards Track
Content-Type:
Victor Stinner victor.stin...@gmail.com:
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
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 ma...@pacujo.net a écrit :
Victor Stinner victor.stin...@gmail.com javascript:;:
Victor Stinner victor.stin...@gmail.com:
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
On 08/31/2014 02:19 PM, Marko Rauhamaa wrote:
Victor Stinner victor.stin...@gmail.com:
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.
Le dimanche 31 août 2014, Marko Rauhamaa ma...@pacujo.net a écrit :
Victor Stinner victor.stin...@gmail.com javascript:;:
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
Victor Stinner victor.stin...@gmail.com:
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
Ethan Furman et...@stoneleaf.us:
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
Le 1 sept. 2014 00:04, Marko Rauhamaa ma...@pacujo.net a écrit :
Victor Stinner victor.stin...@gmail.com:
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
On Mon, 01 Sep 2014 01:15:12 +0300
Marko Rauhamaa ma...@pacujo.net 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
Le 1 sept. 2014 00:17, Marko Rauhamaa ma...@pacujo.net 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
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
On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
On Sun, 31 Aug 2014 20:14:50 -0700, Dan Stromberg drsali...@gmail.com wrote:
On Sun, Aug 31, 2014 at 3:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz
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
R. David Murray rdmur...@bitdance.com:
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
38 matches
Mail list logo
