|
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
[Prev in Thread] | Current Thread | [Next in Thread] |