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

[Rik]

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.


>   Then in the main thread we just wait for the thread to
> finish and periodically check to see whether the
> octave_interrupt_state variable is set.  If it is, then we cancel the
> thread and throw an exception.  That will all happen inside the thread
> that is running the Octave interpreter, so we won't be trying to throw
> an exception across threads.
>
> I understand how to do this with pthreads.  I'll either need help with
> Windows threads or maybe we could use the pthreads-win32 library
> (LGPL; available here: http://www.sourceware.org/pthreads-win32).
>
> Another question is whether we should always use this approach or
> continue to use the setjmp/longjmp method for the CLI version of
> Octave.
I guess it depends on the performance considerations above.  Maintaining
more lines of code is always more work so maybe if we figure out a working
solution we should apply it everywhere.

--Rik
> Does anyone see a better way?
>
> jwe