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

[Daniel J Sebald]

On 11/14/2013 10:46 AM, John W. Eaton 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.

Creative and probably efficient for real-time applications, but hardly 
portable or easy to maintain.


> 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.
>
> We only need to use this approach on Windows systems. The
> pthread_sigmask/pthread_kill solution seems to work fine with systems
> that have pthreads. The win32 pthreads library doesn't have
> pthread_kill, so that won't help us.

John, be sure to check out the QThread::exit() member function

http://qt-project.org/doc/qt-4.7/qthread.html#signalSection

before looking for a Windows alternative.  According to this post:

http://stackoverflow.com/questions/4140189/qthreads-vs-pthreads

Qt uses pthreads.  So, I'd make a guess that QThread::exit() is using 
pthread_kill if that is available.  (I think   Maybe in Windows Qt is 
using something else.

I think QThread::exit might work for what you are describing with long, 
external functions.  But even for the Octave core SIGINT processing it 
might do.  If GUI thread gets the SIGINT when the terminal window is 
active, it could stop the Octave worker thread (remember, exit doesn't 
actually destroy the thread) and then call Octave core routines that 
make up the current SIGINT handling.  The might require some 
restructuring of Octave core routines, but hopefully in a way that 
doesn't make the core dependent upon the GUI.  That's my theory anyway 
(I only looked a couple layers deep):

https://qt.gitorious.org/qt/qt/source/0aca5cf05288dc4d2175d1c4a78bf62a5ea96b21:src/corelib/thread/qthread.cpp
[Look for void QThread::exit(int returnCode)]

https://qt.gitorious.org/qt/qt/source/0aca5cf05288dc4d2175d1c4a78bf62a5ea96b21:src/corelib/kernel/qeventloop.cpp
[Look for void QEventLoop::exit(int returnCode)]

https://qt.gitorious.org/qt/qt/source/0aca5cf05288dc4d2175d1c4a78bf62a5ea96b21:src/corelib/kernel/qeventdispatcher_win.cpp

https://qt.gitorious.org/qt/qt/source/0aca5cf05288dc4d2175d1c4a78bf62a5ea96b21:src/corelib/kernel/qeventdispatcher_unix.cpp

Dan