Re: signal handling

[Paul Kienzle]

On Tue, Nov 05, 2002 at 11:59:41AM -0600, John W. Eaton wrote:
Content-Description: message body text
> I'm thinking about how to improve Octave's signal handling and error
> recovery.  Currently, when Octave receives an interrupt signal, it
> simply tries to use longjump to get back to the beginning of the main
> interpreter loop.  This approach has at least two major problems.
> First, there is no guarantee that a longjump out of a signal handler
> will even work.  Second, it skips over the destructors for all the
> objects that have been created up to the point of the signal, which
> leads to big memory leaks.

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.

I agree that doesn't address the destructor problem, but it does
suggest that you should be using sigsetjmp/siglongjmp in those places
where you cannot use C++ exception handling.

> My proposal is to modify the signal handler so that it simply sets a
> global variable and returns.  Then when Octave hits a QUIT macro, it
> will throw a C++ exception which will be caught at the top level.  If
> we then make sure that all resources are managed properly in object
> constructors/destructors, the exception handling code should take care
> of deleting any temporary objects.  I think that in most instances,
> this is already true, so most of that work is done.  What remains is
> to add calls to QUIT in a number of places in the Octave sources.  To
> see how this method works, compile the example below with
> -DUSE_EXCEPTIONS and try the same experiment as above.  This time, you
> should see the same number of messages from the big_memory_hog
> constructor and destructor so the process should not grow (the total
> size should never be too much more than 8MB).

Can we have a debug_on_interrupt flag so that octave will stop at the
next statement?  This can be useful if you have a long running process.
Hit Ctrl-C, see where it has got to, then continue.  

One problem I see is that you don't know whether the last line ran to
completion or if it was interrupted within an external function.  In a
patch I sent earlier, the first interrupt would set a flag saying stop at
the next statement, but if the user got bored waiting they could hit ctrl-C
again which would see that the flag had been set and abort to the top
level.

Paul Kienzle
address@hidden