Skip to content

gh-72353: WindowsConsoleIO misbehavior when Ctrl+C is ignored #17976

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

gh-72353: WindowsConsoleIO misbehavior when Ctrl+C is ignored #17976

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d52625d
bpo-28166: WindowsConsoleIO misbehavior when Ctrl+C is ignored
ZackerySpytz Jan 13, 2020
1906b29
Merge branch 'main' into bpo-28166-WindowsConsoleIO-Ctrl-C
serhiy-storchaka Dec 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions Misc/NEWS.d/next/Windows/2020-01-12-23-52-49.bpo-28166.dZ-Mz9.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
``WindowsConsoleIO``: Continue to read when interrupted by Ctrl+C if
``SIGINT`` is ignored or the handler doesn't raise an exception.
5 changes: 3 additions & 2 deletions Modules/_io/winconsoleio.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -583,14 +583,15 @@ read_console_w(HANDLE handle, DWORD maxlen, DWORD *readlen) {
break;
err = 0;
HANDLE hInterruptEvent = _PyOS_SigintEvent();
if (WaitForSingleObjectEx(hInterruptEvent, 100, FALSE)
== WAIT_OBJECT_0) {
DWORD state = WaitForSingleObjectEx(hInterruptEvent, 100, FALSE);
if (state == WAIT_OBJECT_0 || state == WAIT_TIMEOUT) {
Copy link
Member

@zooba zooba Feb 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering every other possible result is a hard error (which we're currently ignoring... whoops), I don't think this is the right condition.

Probably in the WAIT_TIMEOUT case we want to just continue and not call PyErr_CheckSignals? We certainly shouldn't reset the event, because we haven't been given it

ResetEvent(hInterruptEvent);
Py_BLOCK_THREADS
sig = PyErr_CheckSignals();
Py_UNBLOCK_THREADS
if (sig < 0)
break;
continue;
}
}
*readlen += n;
Expand Down
5 changes: 3 additions & 2 deletions Parser/myreadline.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,15 +160,16 @@ _PyOS_WindowsConsoleReadline(PyThreadState *tstate, HANDLE hStdIn)
goto exit;
err = 0;
HANDLE hInterruptEvent = _PyOS_SigintEvent();
if (WaitForSingleObjectEx(hInterruptEvent, 100, FALSE)
== WAIT_OBJECT_0) {
DWORD state = WaitForSingleObjectEx(hInterruptEvent, 100, FALSE);
if (state == WAIT_OBJECT_0 || state == WAIT_TIMEOUT) {
ResetEvent(hInterruptEvent);
PyEval_RestoreThread(tstate);
s = PyErr_CheckSignals();
PyEval_SaveThread();
if (s < 0) {
goto exit;
}
continue;
}
break;
}
Expand Down
Loading