Re: signal handling

[John W. Eaton]

On 14-Nov-2002, Paul Kienzle <address@hidden> wrote:

| Here is how the open group defines siglongjmp:
| 
|       http://www.opennc.org/onlinepubs/7908799/xsh/siglongjmp.html
| 
|       As it bypasses the usual function call and return mechanisms,
|       siglongjmp() will execute correctly in contexts of interrupts,
|       signals and any of their associated functions. However, if
|       siglongjmp() is invoked from a nested signal handler (that is, from
|       a function invoked as a result of a signal raised during the
|       handling of another signal), the behaviour is undefined.

Can we guarantee that they will never be called from a nested signal
handler?  The only place we would jump from would be the interrupt
handler, and I think that when it is executing, interrupts are
ignored.  What would happen if we catch an interrupt when some other
signal handler is running?  Would ignoring interrupts inside other
signal handlers solve that problem?  What about signal handlers that
might be installed by "foreign" code?

Hmm.  In any case, you're right that we should be using
sig{set,long}jmp instead, if they exist (and I would expect them to be
present on all modern systems).  I can make that change.

I also thought of another problem.  With my most recent changes, we
now only jump out of the signal handler when executing foreign code
(mostly Fortran) and that should be OK except when the foreign code
calls back to Octave.  For example, fsolve calls a user-defined
function written in C++ which then executes some interpreted Octave
code.  When that code is running, we should avoid jumping so that we
don't leak resources.  This means that the body of the user-supplied
function should be surrounded by a try-catch block and we should set
up to return from the signal handler instead of jumping, then throw
and exception, then jump from the try block back to the point where
the foreign code was intially called.

I can make these changes for the code that is in Octave now, but
unfortunately doing this correctly requires making similar
modifications for any foreign code that calls back to Octave.

jwe