[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 se

[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 ___ ___ Pyt

[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 c

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

Jeroen Demeyer added the comment: Just a comment: if you need really robust signal handling, you just cannot do it with pure Python. I would recommend using Cython, where one has complete control over when signals are checked. -- nosy: +jdemeyer ___

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

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

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

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

[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

Changes by Antoine Pitrou : -- assignee: pitrou -> stage: patch review -> needs patch versions: +Python 3.3 -Python 3.1 ___ Python tracker ___ ___

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

Changes by Nir Aides : -- nosy: +nirai ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/ma

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

Antoine Pitrou 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. -- resolution: dupli

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

Antoine Pitrou 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 issue as duplicate

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

Antoine Pitrou 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 bonus, it's also

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

Charles-Francois Natali added the comment: > Antoine Pitrou 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 o

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

Antoine Pitrou 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 before anything co

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

Georg Brandl added the comment: Antoine? -- assignee: -> pitrou nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list maili

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

Changes by Éric Araujo : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

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

Charles-Francois Natali 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, synchronously, mainly

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

New submission from Alan Wilter : 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, frame ): print(