|
From: | Michael Goffioul |
Subject: | Re: interrupt handing and the GUI (bug #37672) |
Date: | Wed, 13 Nov 2013 15:26:56 -0500 |
On 11/13/2013 02:47 PM, Michael Goffioul wrote:
On Wed, Nov 13, 2013 at 3:24 AM, John W. Eaton <address@hidden<mailto:address@hidden>> wrote:
The implementation for Windows is still calling "::raise (SIGINT)". I
tried using "GenerateConsoleCtrlEvent (CTRL_C_EVENT, 0)" but that
still crashes Octave if it is expecting to be able to longjmp out of
the signal handler back to the most recent "safe" location. I don't
know how to fix this problem yet. If anyone has a clue, help would be
most appreciated.
I don't have a solution to suggest, just some additional information:
- Win32 implementation of "raise" does not generate a real signal, it
simply executes the associated handler if one was installed; if no
handler was installed, I understand it somehow does the same as
GenerateConsoleCtrlEvent [1]
- CTRL-C events are handled in dedicated threads created by the OS; so I
suppose you can simply longjmp from that thread
Michael.
[1] http://msdn.microsoft.com/en-us/library/dwwzkt4c(v=vs.100).aspx
I'm not sure that jumping out of the signal handler works at all. I
just noticed that even with octave-cli (which my recent changes don't
affect because they are all in liboctgui and that is not linked with
octave-cli) that interruptingwhile inv is inside an Lapack function (so longjmp is used) causes
x = rand (3000);
inv (x);
Octave to exit.
Does this work in any previous version of Octave on Windows?
Ah, OK, we used to have some code for switching threads in the signal
handler on Windows. I removed it in this changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/24e755668237
because it didn't seem to be necessary and because it was
not compiling for 64-bit Windows.
I also remember that you warned me about removing this code and said
that you were surprised that interrupts worked at all without it. I
guess interrupts appeared to work OK when the signal handler was just
setting the global interrupt state variable but I never properly
tested it for cases where the interrupt handler will do
setjmp/longjmp.
I'll restore this code and see what happens. But even if it works, we
will still need a solution for 64-bit Windows.
[Prev in Thread] | Current Thread | [Next in Thread] |