[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: interrupt handing and the GUI (bug #37672)
From: |
Daniel J Sebald |
Subject: |
Re: interrupt handing and the GUI (bug #37672) |
Date: |
Fri, 15 Nov 2013 00:28:00 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16 |
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
- Re: interrupt handing and the GUI (bug #37672), (continued)
- Re: interrupt handing and the GUI (bug #37672), John W. Eaton, 2013/11/11
- Re: interrupt handing and the GUI (bug #37672), John Swensen, 2013/11/11
- Re: interrupt handing and the GUI (bug #37672), Michael Goffioul, 2013/11/11
- Re: interrupt handing and the GUI (bug #37672), John W. Eaton, 2013/11/13
- Re: interrupt handing and the GUI (bug #37672), Thorsten Liebig, 2013/11/13
- Re: interrupt handing and the GUI (bug #37672), Thorsten Liebig, 2013/11/13
- Message not available
- Re: interrupt handing and the GUI (bug #37672), John W. Eaton, 2013/11/13
- Re: interrupt handing and the GUI (bug #37672), Michael Goffioul, 2013/11/13
- Re: interrupt handing and the GUI (bug #37672), John W. Eaton, 2013/11/14
- Re: interrupt handing and the GUI (bug #37672), Michael Goffioul, 2013/11/14
- Re: interrupt handing and the GUI (bug #37672),
Daniel J Sebald <=
- Re: interrupt handing and the GUI (bug #37672), Michael Goffioul, 2013/11/15
- Re: interrupt handing and the GUI (bug #37672), John W. Eaton, 2013/11/11
Re: interrupt handing and the GUI (bug #37672), Michael D. Godfrey, 2013/11/10
Re: interrupt handing and the GUI (bug #37672), Rik, 2013/11/10