[issue10478] Ctrl-C locks up the interpreter

Antoine Pitrou added the comment: Fixed in r86981 (3.2), r86987 (3.1) and r86992 (2.7). Thanks! -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue10478] Ctrl-C locks up the interpreter

STINNER Victor added the comment: Ok, so +1 to apply immediatly your patch which "fixes" the deadlock. If someone is motived to make Buffered* classes reentrant, (s)he can remove this exception. io and signal documentation should also be improved to indicate that using buffered I/O in a signa

[issue10478] Ctrl-C locks up the interpreter

Antoine Pitrou added the comment: > This issue remembers me #3618 (opened 2 years ago): I proposed to use > RLock instead of Lock, but RLock was implemented in Python and were > too slow. Today, we have RLock implemented in C and it may be possible > to use them. Would it solve this issue? I th

[issue10478] Ctrl-C locks up the interpreter

Changes by STINNER Victor : -- Removed message: http://bugs.python.org/msg123242 ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue10478] Ctrl-C locks up the interpreter

STINNER Victor added the comment: This issue remembers me #3618 (opened 2 years ago): I proposed to use RLock instead of Lock, but RLock was implemented in Python and were too slow. Today, we have RLock implemented in C and it may be possible to use them. Would it solve this issue? -- There

[issue10478] Ctrl-C locks up the interpreter

STINNER Victor added the comment: This issue remembers me #3618 (opened 2 years ago): I proposed to use RLock instead of Lock, but RLock was implemented in Python and were too slow. Today, we have RLock implemented in C and it may be possible to use them. Would it solve this issue? -- There

[issue10478] Ctrl-C locks up the interpreter

STINNER Victor added the comment: Dummy question: why don't you use KeyboardInterrupt instead of a custom SIGINT handler? try: for i in range(100): print(i) except KeyboardInterrupt: print("got sigint") Python SIGINT handler raises a KeyboardInterrupt (the handler is writt

[issue10478] Ctrl-C locks up the interpreter

Changes by Antoine Pitrou : -- nosy: +stutzbach ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue10478] Ctrl-C locks up the interpreter

Antoine Pitrou added the comment: > Would avoiding PyErr_CheckSignals() while the file object is in > inconsistent state be a reasonable alternative? No, because we'd like IO operations to be interruptible by the user (e.g. pressing Ctrl-C) when they would otherwise block indefinitely. > I am

[issue10478] Ctrl-C locks up the interpreter

Ilya Sandler added the comment: Would avoiding PyErr_CheckSignals() while the file object is in inconsistent state be a reasonable alternative? I am guessing that it's not that uncommon for a signal handler to need IO (e.g to log a signal). If making IO safer is not an option, then I think,

[issue10478] Ctrl-C locks up the interpreter

Changes by Antoine Pitrou : -- stage: -> patch review versions: +Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list m

[issue10478] Ctrl-C locks up the interpreter

Antoine Pitrou added the comment: Here is a patch raising RuntimeError on reentrant calls to a buffered object. I haven't touched _pyio; I wonder how to do it without making it even slower. -- keywords: +patch Added file: http://bugs.python.org/file19841/reentrantio.patch

[issue10478] Ctrl-C locks up the interpreter

Changes by Antoine Pitrou : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue10478] Ctrl-C locks up the interpreter

Antoine Pitrou added the comment: Wow. The lock is precisely there so that the buffered object doesn't have to be MT-safe or reentrant. It doesn't seem reasonable to attempt to restore the file to a "stable" state in the middle of an inner routine. Also, the outer TextIOWrapper (we're talking

[issue10478] Ctrl-C locks up the interpreter

Amaury Forgeot d'Arc added the comment: I reproduce the problem, see the call stack below. The issue is in the io module: the function _bufferedwriter_flush_unlocked() runs with the file mutex already acquired, but it calls PyErr_CheckSignals() which may run any code, including flush() on the

[issue10478] Ctrl-C locks up the interpreter

New submission from Ilya Sandler : The following program is misbehaving with python3.2 import signal, time def sighandler( arg1, arg2): print("got sigint");assert 0 signal.signal( signal.SIGINT, sighandler) for i in range(100): print(i) I'd expect Ctrl-C to terminate the prog