octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John W. Eaton
Subject: Re: interrupt handing and the GUI (bug #37672)
Date: Wed, 13 Nov 2013 15:22:41 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

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 interrupting

  x = rand (3000);
  inv (x);

while inv is inside an Lapack function (so longjmp is used) causes
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.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]