KeyboardInterrupt on Windows

I received this problem report (Kurt is the IDLEFORK developer). Does anybody know what could be the matter here? What changed recently??? --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Fri, 30 May 2003 15:50:15 -0400 From: kbk@shore.net (Kurt B. Kaiser) To: Guido van Rossum <guido@python.org> Subject: KeyboardInterrupt I find that while 1: pass doesn't respond to a KeyboardInterrupt on Python2.3b1 on either WinXP or W2K. Is this generally known? I couldn't find any mention of it. while 1: a = 0 is fine on 2.3b1, and both work on Python2.2. - -- KBK ------- End of Forwarded Message

On Fri, May 30, 2003 at 04:35:53PM -0400, Guido van Rossum wrote:
I received this problem report (Kurt is the IDLEFORK developer). Does anybody know what could be the matter here? What changed recently???
Could this be from the optimization Raymond did:
def f(): ... while 1: pass
3 jumps to 10, 10 jumps to itself unless I'm reading this wrong. See Python/compile.c::optimize_code (starting around line 339) Neal

On Fri, May 30, 2003 at 04:40:00PM -0400, Neal Norwitz wrote:
The patch below fixes the problem by not optimizing while 1:pass. Seems kinda hacky though. Neal -- Index: Python/compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.289 diff -w -u -r2.289 compile.c --- Python/compile.c 22 May 2003 22:00:04 -0000 2.289 +++ Python/compile.c 30 May 2003 21:02:26 -0000 @@ -411,6 +411,8 @@ tgttgt -= i + 3; /* Calc relative jump addr */ if (tgttgt < 0) /* No backward relative jumps */ continue; + if (i == tgttgt && opcode == JUMP_ABSOLUTE) + goto exitUnchanged; codestr[i] = opcode; SETARG(codestr, i, tgttgt); break;

[Guido]
I received this problem report (Kurt is the IDLEFORK developer). Does anybody know what could be the matter here? What changed recently???
Looks like eval-loop optimizations. The first version essentially compiles to a JUMP_ABSOLUTE to itself >> 10 JUMP_ABSOLUTE 10 and case JUMP_ABSOLUTE: JUMPTO(oparg); goto fast_next_opcode; This skips the ticker checks, so never checks for interrupts. As usual, I expect we can blame Raymond Hettinger's good intentions <wink>.

It's probably an unintended consequence of the "while 1" optimization and the fast-next-opcode optimization. "while 1" doesn't do a test at runtime anymore. And opcodes like JUMP_ABSOLUTE bypass the test for pending exceptions. The next result is that while 1: pass puts the interpreter in a tight loop doing a JUMP_ABSOLUTE that goes nowhere. That is offset X has JUMP_ABSOLUTE X. I'd be inclined to call this a bug, but I'm not sure how to fix it. Jeremy

Jeremy Hylton <jeremy@zope.com> writes:
Take out the while 1: optimizations? I don't want to belittle Raymond's efforts, but I am conscious of[1] Tim's repeated observations of the correlation between the number of optimizations in the compiler and the number of weird bugs therein. Cheers, M. [1] I'm also warming up for a end-of-PyPy-sprint drunken hacking session so you probably shouldn't take me too seriously :-) -- ARTHUR: Why should a rock hum? FORD: Maybe it feels good about being a rock. -- The Hitch-Hikers Guide to the Galaxy, Episode 8

Jeremy Hylton wrote:
I'd be inclined to call this a bug, but I'm not sure how to fix it.
I think right the fix it to make JUMP_ABSOLUTE not bypass the test for pending exceptions. We have to be really careful with using fast_next_opcode. Originally it was only used by SET_LINENO, LOAD_FAST, LOAD_CONST, STORE_FAST, POP_TOP. Using it from jump opcodes is asking for trouble, IMHO. Shall I prepare a patch? Neil

On Fri, May 30, 2003 at 04:35:53PM -0400, Guido van Rossum wrote:
I received this problem report (Kurt is the IDLEFORK developer). Does anybody know what could be the matter here? What changed recently???
Could this be from the optimization Raymond did:
def f(): ... while 1: pass
3 jumps to 10, 10 jumps to itself unless I'm reading this wrong. See Python/compile.c::optimize_code (starting around line 339) Neal

On Fri, May 30, 2003 at 04:40:00PM -0400, Neal Norwitz wrote:
The patch below fixes the problem by not optimizing while 1:pass. Seems kinda hacky though. Neal -- Index: Python/compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.289 diff -w -u -r2.289 compile.c --- Python/compile.c 22 May 2003 22:00:04 -0000 2.289 +++ Python/compile.c 30 May 2003 21:02:26 -0000 @@ -411,6 +411,8 @@ tgttgt -= i + 3; /* Calc relative jump addr */ if (tgttgt < 0) /* No backward relative jumps */ continue; + if (i == tgttgt && opcode == JUMP_ABSOLUTE) + goto exitUnchanged; codestr[i] = opcode; SETARG(codestr, i, tgttgt); break;

[Guido]
I received this problem report (Kurt is the IDLEFORK developer). Does anybody know what could be the matter here? What changed recently???
Looks like eval-loop optimizations. The first version essentially compiles to a JUMP_ABSOLUTE to itself >> 10 JUMP_ABSOLUTE 10 and case JUMP_ABSOLUTE: JUMPTO(oparg); goto fast_next_opcode; This skips the ticker checks, so never checks for interrupts. As usual, I expect we can blame Raymond Hettinger's good intentions <wink>.

It's probably an unintended consequence of the "while 1" optimization and the fast-next-opcode optimization. "while 1" doesn't do a test at runtime anymore. And opcodes like JUMP_ABSOLUTE bypass the test for pending exceptions. The next result is that while 1: pass puts the interpreter in a tight loop doing a JUMP_ABSOLUTE that goes nowhere. That is offset X has JUMP_ABSOLUTE X. I'd be inclined to call this a bug, but I'm not sure how to fix it. Jeremy

Jeremy Hylton <jeremy@zope.com> writes:
Take out the while 1: optimizations? I don't want to belittle Raymond's efforts, but I am conscious of[1] Tim's repeated observations of the correlation between the number of optimizations in the compiler and the number of weird bugs therein. Cheers, M. [1] I'm also warming up for a end-of-PyPy-sprint drunken hacking session so you probably shouldn't take me too seriously :-) -- ARTHUR: Why should a rock hum? FORD: Maybe it feels good about being a rock. -- The Hitch-Hikers Guide to the Galaxy, Episode 8

Jeremy Hylton wrote:
I'd be inclined to call this a bug, but I'm not sure how to fix it.
I think right the fix it to make JUMP_ABSOLUTE not bypass the test for pending exceptions. We have to be really careful with using fast_next_opcode. Originally it was only used by SET_LINENO, LOAD_FAST, LOAD_CONST, STORE_FAST, POP_TOP. Using it from jump opcodes is asking for trouble, IMHO. Shall I prepare a patch? Neil
participants (7)
-
Guido van Rossum
-
Jeremy Hylton
-
Michael Hudson
-
Neal Norwitz
-
Neil Schemenauer
-
Raymond Hettinger
-
Tim Peters