Re: signal handling

[Paul Kienzle]

On Thu, Nov 14, 2002 at 03:57:22PM -0600, John W. Eaton wrote:
> 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? 

We can using sigaction, which allows you to mask signals while the handler
is active.

> The only place we would jump from would be the interrupt
> handler, and I think that when it is executing, interrupts are
> ignored.

I can't find anything definitive about that for signal().

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

Foreign code should set and restore the signal handlers that it needs.

> 
> 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 played with this a long time ago, and I'm rusty on the details.  The
foreign code has to be compiled with -fexceptions, but from the signal
handler can't you simply throw an exception as usual?  I believe I was
throwing the exception in the callback rather than the from the signal
handler, but the idea is the same.

If the foreign code has acquired resource they won't be released (C++
doesn't know about them), but that is true even if you use siglongjmp
as you are suggesting.  The only way around it that I can see is if
the foreign code can register and invoke unwind_protect code much like
you are doing things now.

Oh, but a lot of the code we are calling (e.g., atlas) may not have
been compiled with -fexceptions, and that might mean we can't throw
an exception from a signal invoked while that code is active.  We need
to try this on various platforms.

The matlab solution, by the way, is to require resource allocation
via matlab functions so that the can be automatically released when your
function exits unless you insist that the resources are persistent.

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

Which is not that much.  I'm assuming most oct files would not be classed
as foreign.

Paul Kienzle
address@hidden