From octave-maintainers-request at bevo dot che dot wisc dot edu Fri Jan 10 12:15:33 2003
Subject: Re: ROctave
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Duncan Temple Lang <duncan at research dot bell-labs dot com>
Cc: octave-maintainers mailing list <octave-maintainers at bevo dot che dot wisc dot edu>
Date: Fri, 10 Jan 2003 12:15:10 -0600

On 10-Jan-2003, Duncan Temple Lang <duncan at research dot bell-labs dot com> wrote:

| I finally got a chance to get to this and put Octave inside R.  Thanks
| for making those changes. It is a great start and I made some trivial
| additions to conditionally activate different parts of the code. I've
| attached the patch file for the 3 files that were modified.  With
| those changes compiled into liboctave and calling octave_main() with
| the new 3rd argument - embedded - as 1, I get the Octave engine
| without the octave event/input loop.

OK.

| We could, of course, also split the octave_main into more pieces, some
| common and some specific to interactive use, and have main() be
| slightly more complex. Either works well for me; more routines gives
| greater customizability at the expense of complexity. So sticking with
| arguments to octave_main() might be simplest, and that is what I was
| going for.  If we also want to allow conditional startup of the I/O
| system, etc.  then we may want a general options object or
| split the material into multiple routines.

For now, I don't think it matters whether it is one function with an
argument or a set of functions, though we may want that later.

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.

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.

Or am I missing something?

jwe