[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Change by Terry J. Reedy : -- versions: +Python 3.9 -Python 2.7, Python 3.6, Python 3.7 ___ Python tracker ___ ___ Python-bugs-list

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Martin Panter added the comment: I doubt the Gnu Readline library nor Python’s readline module are relevant. The input function only uses Readline if sys.stdin is the original stdin terminal; I suspect Idle monkey-patches sys.stdin. The readline method reads directly from the file object; it

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Antoine Pitrou added the comment: Github links to the aforementioned changesets: "added PyErr_SetInterrupt(); NT ifdefs" https://github.com/python/cpython/commit/06d511ddf5fe16468a3abd53344fa283b9981d73 "Add interrupt_main() to thread module."

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Antoine Pitrou added the comment: Also note that: - PyErr_SetInterrupt() has been setting the SIGINT since the beginning in 1995 (changeset 06d511dd by Guido) - interrupt_main() has been calling PyErr_SetInterrupt() since the beginning in 2003 (changeset a11e8461 by Kurt B Kaiser) so it

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Antoine Pitrou added the comment: Note that, since interrupt_main() claims to interrupt the main thread, it would be ok to use pthread_kill() to make sure it's indeed the C syscall running in the main thread that gets interruped. -- ___ Python

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Antoine Pitrou added the comment: Please step back a bit and read the implementation of interrupt_main(): it calls PyErr_SetInterrupt() (in signalmodule.c!), which merely sets an internal flag saying SIGINT was received. So, there: PyErr_SetInterrupt() already behaves like SIGINT, *except*

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Nathaniel Smith added the comment: Then maybe simplest solution is to scale back the claim :-). The important semantic change would be that right now, interrupt_main() is documented to cause KeyboardInterrupt to be raised in the main thread. So if you register a custom SIGINT handler that

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Eryk Sun added the comment: The strong claim that "interrupt_main is now equivalent to the user having hit control-C" is the reason I suggested broadcasting CTRL_C_EVENT via GenerateConsoleCtrlEvent. That operation isn't buggy on its own to my knowledge. There is a glitch due to the CRT. If a

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Antoine Pitrou added the comment: +1 on having PyErr_SetInterrupt() call raise(SIGINT) or equivalent. -- nosy: +pitrou ___ Python tracker ___

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Nathaniel Smith added the comment: > A real Ctrl+C executes the registered control handlers for the process. Right, but it's *extremely* unusual for a python 3 program to have a control handler registered directly via SetConsoleCtrlHandler. This isn't an API that the interpreter uses or

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Terry J. Reedy added the comment: It appears you are right about open('con'...). However, this issue is about the fact that >>> import time; time.sleep(10) ^C ... KeyboardInterrupt works in the console but does not work in the IDLE Shell in default mode. In default mode (-n not on the

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Eryk Sun added the comment: Terry, I assume you ran IDLE via pyw.exe or pythonw.exe, which won't inherit the console of its parent. You have to use py.exe or python.exe. In this case you can also use sys.__stdout__.write('spam\n'). If you run via pythonw.exe or pyw.exe from a command prompt,

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Eryk Sun added the comment: > interrupt_main is now equivalent to the user having hit control-C. That's true on a POSIX system with pthread_kill, but not really for a Windows process that's attached to a console. A real Ctrl+C executes the registered control handlers for the process.

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Nathaniel Smith added the comment: Sorry, I meant bpo-21895. -- ___ Python tracker ___ ___ Python-bugs-list

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Nathaniel Smith added the comment: In terms of general design cleanliness, I think it would be better to make `interrupt_main` work reliably than to have IDLE add workarounds for its unreliability. AFAICT the ideal, minimal redundancy solution would be: - interrupt_main just calls

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Terry J. Reedy added the comment: On windows, s=input() is cleanly interrupted by ^-C, leaving s unbound, before and after the patch. time.sleep(1) is not interrupted, before and after the patch. Ditto for the socket test. Louie, what test are you using on *nix? It still appears that for

[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()

Changes by Louie Lu : -- assignee: -> terry.reedy components: +IDLE -Library (Lib) title: time.sleep ignores _thread.interrupt_main() -> IDLE: in shell, time.sleep ignores _thread.interrupt_main() ___ Python tracker