[Top][All Lists]

[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: Sun, 10 Nov 2013 15:52:06 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

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
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.


reply via email to

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