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

[John W. Eaton]

On 11/10/2013 03:18 PM, Rik wrote:
> On 11/10/2013 09:08 AM, address@hidden wrote:
> > Here is my proposed solution:
> >
> > Instead of using setjmp/longjmp and relying on Unix signal handling to
> > interrupt the process, we execute these long-running external
> > functions in separate threads that we can cancel when an interrupt
> > arrives.
> How is it determined what might be a long-running external function?
> sleep() can be either very short (sleep (0.01)) or very long (sleep (10)).
> It seems like it would be difficult to program the AI needed for each function.
>
> Would the determination of "long-running" be done on a case-by-case basis
> in the code or do we assume that any external library function might
> potentially be long?  I would worry in that case that someone with fread()
> might have the the overhead of setting up, launching a thread, and cleaning
> up all to read a single value.

For the most part we've already made this distinction.  The functions 
that are called with F77_XFCN (but not F77_FUNC or F77_FCN) and any 
block of code surrounded by 
{BEGIN,END}_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE are subject to the 
setjmp/longjmp signal handling treatment.

So for those bits of code we already have the overhead of copying the 
setjmp info, calling setjmp, and the restoring the setjmp info.  We 
would just be replacing that with the thread creation and 
octave_interrupt_state detection code.

In any case, we could examine any of the locations where F77_XFCN or 
{BEGIN,END}_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE is used and skip that 
if the operation is expected to be fast.  For example, in the code for 
computing a matrix inverse, we might choose to skip thread creation or 
the setjmp/longjmp setup if the size of the matrix is less than some 
threshold.  For iterative solvers there is probably no general way to 
determine whether they will be fast.

jwe