[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53635] CTRL-C does not work in all instances

From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #53635] CTRL-C does not work in all instances when using Windows GUI
Date: Thu, 19 Apr 2018 11:10:07 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #26, bug #53635 (project octave):

OK, I decided to try again with Windows.  Since I removed the call

GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0);

in http://hg.savannah.gnu.org/hgweb/octave/rev/4adeabc1bbfe, things like

system ("sleep 10");

can't be interrupted on Windows systems.  So I thought I would try again, and
made the following change:

diff --git a/libgui/src/terminal-dock-widget.cc
--- a/libgui/src/terminal-dock-widget.cc
+++ b/libgui/src/terminal-dock-widget.cc
@@ -27,6 +27,10 @@ along with Octave; see the file COPYING.
 #include <QDesktopWidget>
+#  include <windows.h>
 #include "quit.h"
 #include "signal-wrappers.h"
@@ -113,6 +117,12 @@ namespace octave
     octave_signal_caught = 1;
+    GenerateConsoleCtrlEvent (CTRL_BREAK_EVENT, 0);
     // Send SIGINT to all other processes in our process group.
     // This is needed to interrupt calls to system (), for example.
@@ -120,5 +130,7 @@ namespace octave
     octave_get_sig_number ("SIGINT", &sigint);
     octave_kill_wrapper (0, sigint);

I used CTRL_BREAK_EVENT instead of CTRL_C_EVENT because
https://docs.microsoft.com/en-us/windows/console/generateconsolectrlevent says
the following about CTRL_C_EVENT:

Generates a CTRL+C signal. This signal cannot be generated for process groups.
If dwProcessGroupId is nonzero, this function will succeed, but the CTRL+C
signal will not be received by processes within the specified process group.

Indeed, this change allows

system ("sleep 10")

to be interrupted.  But it also brings back the hanging behavior with Ctrl-C
dwhen __run_test_suite__ is executing.  While Octave appears to be stuck, I
can use the task manager to kill the cmd.exe that (I think) Octave is starting
when processing doc strings for usage messages and then control will return to
the Octave prompt.  So the question is, why does *that* use of cmd.exe hang
but not the cmd.exe that is started to execute the "sleep" process?

I guess hanging the whole Octave process is worse than not being able to
interrupt subprocesses?  So, while it would be best to make this work as it
does now on POSIX systems, that will probably have to wait until after the
release unless someone else has some insight and a fix.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]