Re: interrupt handing and the GUI (bug #37672)

[Michael Goffioul]

On Thu, Nov 14, 2013 at 11:46 AM, John W. Eaton <address@hidden> wrote:

On 11/13/2013 03:26 PM, Michael Goffioul wrote:

That code was not working ok either, as far as I remember. Sometimes
Ctrl-C would make octave to exit. I have an idea I'd like to experiment
with when I get some time, but in the meantime you can restore that code.

I'm not sure it makes sense to restore it.

I think we have been trying to do the impossible in the way we have
been handling SIGINT on Windows systems when we want to interrupt
external library code by doing setjmp/longjmp from the signal handler.

The Windows docs for signal handling and longjmp both specifically
state that longjmp should not be used to transfer control out of an
interrupt-handling routine unless the interrupt is caused by a
floating-point exception.

  http://msdn.microsoft.com/en-us/library/3ye15wsy%28v=vs.90%29.aspx
  http://msdn.microsoft.com/en-us/library/xdkz3x12%28v=vs.90%29.aspx

The code I removed earlier in the year was trying to be clever and
fake it by manipulating CPU registers, I think.  The code was copied
from clisp and it seems that it will only sort of work on 32-bit
Windows anway.

I believe it doesn't compile in Win64, because it uses CPU-specific structures (the CONTEXT struct) and the code needs to be adapted to x86_64 architecture. Looking at the following link (see pthread_cancel implementation, which uses the same idea), the difference seems pretty limited:

http://locklessinc.com/articles/pthreads_on_windows/

 

Unless anyone has a better suggestion, then I guess I'm back at my
idea of starting a thread for calculations that might run for a while
and then canceling them if an interrupt arrives.

I would like to try a simplified version of the previous code (inherited from CLISP). I made several tests yesterday with prototype code, using longjmp/setmp, and it worked reliably, at least within the simple test program I used, when compiled with /EHa (which provides C++ stack unwinding; otherwise /EHsc also worked fine, but without C++ stack unwinding).

However, what I notice is that CTRL-C behavior is different when you run the program in MSYS/bash or in Win32 command prompt. The CTRL-C handling worked only as expected in the Win32 command prompt; I think MSYS/bash must do something internally to also process CTRL-C events. So if you test CTRL-C behavior by running octave from bash, you might be fooled by that aspect.

Michael.