[issue9504] signal.signal/signal.alarm not working as expected

Change by Irit Katriel : -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue9504] signal.signal/signal.alarm not working as expected

STINNER Victor added the comment: https://www.python.org/dev/peps/pep-0475/ changed deeply how Python handles signals. Python now tries to restart syscalls interrupted by signals (EINTR). A Python function only raises an exception if the Python signal handler raises an exception.

[issue9504] signal.signal/signal.alarm not working as expected

Irit Katriel added the comment: I'm unable to reproduce this on 3.11 on a Mac. Has it been fixed? -- nosy: +iritkatriel status: open -> pending ___ Python tracker ___

[issue9504] signal.signal/signal.alarm not working as expected

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

[issue9504] signal.signal/signal.alarm not working as expected

STINNER Victor added the comment: I don't understand this issue. I would expect that a system call fails with EINTR if it is interrupted by a signal. Python explicitly configures the C library to get EINTR errors: automatic retry is disabled when Python sets its signal handlers. If a system

[issue9504] signal.signal/signal.alarm not working as expected

Martin Panter added the comment: Okay, I tend to agree, and don’t have a problem with rejecting this. -- ___ Python tracker ___

[issue9504] signal.signal/signal.alarm not working as expected

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue9504] signal.signal/signal.alarm not working as expected

Martin Panter added the comment: With Python’s current technique for signal handling, I think there is always going to be a window where a signal can arrive at the low level after checking the Python flag and before starting a blocking call. If you need to robustly handle a signal maybe it is

[issue9504] signal.signal/signal.alarm not working as expected

Martin Panter added the comment: Sorry, EINTR changes were PEP 475. -- ___ Python tracker ___ ___

[issue9504] signal.signal/signal.alarm not working as expected

Changes by Antoine Pitrou pit...@free.fr: -- assignee: pitrou - stage: patch review - needs patch versions: +Python 3.3 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9504 ___

[issue9504] signal.signal/signal.alarm not working as expected

Changes by Nir Aides n...@winpdb.org: -- nosy: +nirai ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9504 ___ ___ Python-bugs-list mailing list

[issue9504] signal.signal/signal.alarm not working as expected

Antoine Pitrou pit...@free.fr added the comment: It seems that my patch for issue10956 also fixes this issue (although it doesn't try to fix FileIO). It also has tests and fixes read() as well as write(). I'm sorry for not noticing that the two issues were so similar. Suggest closing this

[issue9504] signal.signal/signal.alarm not working as expected

Antoine Pitrou pit...@free.fr added the comment: Sorry, bad analysis. The patch in issue10956 only seemed to work because my system is too fast and find / in the script returned in less than 5 seconds. Replacing it with yes shows that the two issued are actually independent. --

[issue9504] signal.signal/signal.alarm not working as expected

Antoine Pitrou pit...@free.fr added the comment: Charles-François' analysis seems to be right. Note that the actual issue here is that read() always succeeds, returning a partial result (because you're executing a command, 'find /', which outputs a lot of data). If read() were interrupted

[issue9504] signal.signal/signal.alarm not working as expected

Charles-Francois Natali neolo...@free.fr added the comment: Antoine Pitrou pit...@free.fr added the comment: Charles-François' analysis seems to be right. Note that the actual issue here is that read() always succeeds, returning a partial result (because you're executing a command, 'find

[issue9504] signal.signal/signal.alarm not working as expected

Antoine Pitrou pit...@free.fr added the comment: Attached is a tentative patch: it checks for pending signals inside _bufferedreader_read_generic, fileio_readall, and rawiobase_readall. I tested quickly on regular files and on pipes, and handlers are now called on time. As a an obvious

[issue9504] signal.signal/signal.alarm not working as expected

Charles-Francois Natali neolo...@free.fr added the comment: It's due to the way the python interpreter handles signals: when the signal is received, python runs a stub signal handler that just sets a flag indicating that the signal has been received: the actual handler is executed later,

[issue9504] signal.signal/signal.alarm not working as expected

Changes by Éric Araujo mer...@netwok.org: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9504 ___ ___ Python-bugs-list mailing

[issue9504] signal.signal/signal.alarm not working as expected

Georg Brandl ge...@python.org added the comment: Antoine? -- assignee: - pitrou nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9504 ___

[issue9504] signal.signal/signal.alarm not working as expected

New submission from Alan Wilter alanwil...@gmail.com: I have this example code to illustrate a problem I am having with python3. It works fine with python 2.6 and 2.7 but does not with python 3.1. from __future__ import print_function import os, subprocess, signal def signal_handler( signum,