Re: ROctave

[Duncan Temple Lang]

John W. Eaton wrote:
> On 10-Jan-2003, Duncan Temple Lang <address@hidden> wrote:
> 

> In your patch, you have
> 
>    if(!embedded)
>       install_signal_handlers ();
> 
> which I think is a problem.  If you avoid setting up signal handlers
> for Octave, then what happens when an interrupt signal is received
> while the Octave interpreter is running?  Currently, Octave's SIGINT
> handler sets a flag and returns, allowing execution to continue until
> it is safe to throw a C++ exception that will return control to the
> top-level event loop.  Doing that ensures that destructors for objects
> on the stack are properly destroyed.  If you skip that by not
> installing Octave's signal handlers, then you are asking for memory
> leaks or even possibly leaving some object in an inconsistent state,
> which could cause unpredictible results on later calls.

Yep, this needs to be worked out carefully and I went for the safe way
of getting control back to the host application (R in this case)
unconditionally. But in all the other inter-system interfaces we have
done, exception handling and general control flow in the case of
errors is the thing that needs the most technical attention to the
specifics. When we embed R in other things, we use a R_tryEval() which
guarantees to return to that spot, not the event loop since that may
not be activated.

> 
> It seems that if octave_main is called with embedded = 1, we still
> need to initialize the signal handlers, but do something different
> when a signal is encountered.  Something like
> 
>   save original signal handler
>   set up octave signal handler
> 
> and then when a signal happens:
> 
>   perform octave cleanup
>   restore original signal handler
>   raise signal again, so the orignal handler can catch it
> 
> This would probably need to happen on each call to the Octave
> interpreter, and each function that the embeddable Octave exports
> would need to be wrapped by a try-catch block to allow it to catch an
> octave_interrupt exception.  This should work fine if we only have a
> few functions to export.


Yep, that's what we do in R and I think should work just fine.  We
have the R_tryEval() or else one can establish a customized "CONTEXT"
which will trap the jumps and allow one to handle these in a special
way. So definitely we need to do something along these lines for Octave.
As I mention, I just wanted to ensure we didn't throw the exception
and have nobody catch it or jump to the octave loop that wasn't actually
running. So hopefully that explains why I put the if(!embedded) there.


Thanks,
  D.

> 
> Or am I missing something?
> 
> jwe