|
From: | Michael Goffioul |
Subject: | Re: interrupt handing and the GUI (bug #37672) |
Date: | Fri, 15 Nov 2013 08:41:00 -0500 |
On 11/14/2013 10:46 AM, John W. Eaton wrote:Creative and probably efficient for real-time applications, but hardly portable or easy to maintain.
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.
John, be sure to check out the QThread::exit() member function
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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |