[Top][All Lists]

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

[Octave-bug-tracker] [bug #52757] cntrl-C crash

From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #52757] cntrl-C crash
Date: Tue, 2 Jan 2018 12:23:45 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0

Follow-up Comment #22, bug #52757 (project octave):

Sorry for the delay.  As I was looking at this issue and trying to write a
summary of interrupt handling in Octave I ran into more trouble and confusion.
 Briefly, the problem is that any library that we use may start threads. 
Because we don't block signals, any thread may end up handling SIGINT.  If
this happens in a section of code that is set to have interrupts processed
immediately (by calling longjmp to return to the point of the library call)
bad things will happen because the longjmp is happening in a different thread
from where the corresponding setjmp was called.  We are almost sure to screw
up the stack.

I'm attaching an example program that uses a slightly different approach to
handle SIGINT when multiple threads may be active.  We might be able to use
this approach in Octave.  It fixes part of the problem (signals vs. multiple
threads) but it raises other issues (responsiveness to signals when calling
library functions).  The basic idea is to block interrupts in all but one
thread.  That thread simply waits for SIGINT to arrive and when it does, sets
a variable to indicate that an interrupt has arrived.  Then, as in Octave,
that variable is checked periodically to see whether an interrupt has
occurred, and if so, some action is taken to interrupt the main process.

Note that with this approach, any library code called from the main thread
will not respond to SIGINT because we have it blocked.  And if a library
function unblocks SIGINT, we may have trouble because now we are waiting for
SIGINT and the library also expects to handle it.  This issue extends to
readline, so we will need to do something different to allow interrupts to be
handled when readline is waiting for input.  Also note that we can't just
throw an exception from a readline event hook function because readline will
not clean up after itself if an exception is thrown.  (As a side note, we
should check to ensure that any code that may be executed in the readline
event hook function also will not throw an exception.)

I'm working on a patch that implements this approach to signal handling for
Octave.  I'll comment here again when it's ready to try.

(file #42789)

Additional Item Attachment:

File name: thread-sig.cc                  Size:10 KB


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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