Re: Win32 CTRL-C handling (Was: interrupt handing and the GUI (bug #37672))

[Michael Goffioul]

On Tue, Nov 19, 2013 at 11:21 AM, John W. Eaton <address@hidden> wrote:

On 11/19/2013 08:01 AM, Michael Goffioul wrote:

That's because when using the GUI, no signal is really generated at the
OS-level. The signal is raised in the octave process; bu raising a
signal in Win32 simply means executing its handler. So SIGINT is not
seen by the child processes. I tried to use GenerateConsoleCtrlEvent,
but it exited octave instead of executing the ctrl-c handler. There's
something I'm missing there, this requires further investigation.

But don't you have the same issue in Linux? Or does pthread_kill
propagates to child processes?

I see.  Yes, it is the same problem in the GUI.  But it works with the CLI version on Linux, but not on my Windows build.

I'll see whether I can change that.

 

On Windows with your patch for interrupt handling, interrupts in the GUI seem to be working reasonably well except for the problem with the system function.  When I run octave-cli in an MSYS shell, Ctrl-C at teh command prompt (while readline is waiting for input) doesn't have nay effect

I explained that behavior previously: it's because readline is using _getch() internally, and the Win32 implementation of that function explicitly disables system-processing of CTRL-C; _getch() is simply returning 0x3 (ascii version of CTRL-C).

 

and Ctrl-C at other times (during a function call or loop execution) exits the Octave process.  If I use octave --no-gui-libs, then strange things happen after Ctrl-C causes Octave to exit.  I then see alternating MSYS shell prompts and Octave prompts and neither works properly.

I also explained that behavior previously: MSYS bash is playing tricks on you (somehow, it must also catch the CTRL-C event and process it to kill the foreground process). Try to execute octave in a regular windows command prompt, you'll get the expected behavior.

Michael.