[Octave-bug-tracker] [bug #34438] Feature Request: Return value from .oct after octave_signal_caught

[Henrik Alsing Friberg]

URL:
  <http://savannah.gnu.org/bugs/?34438>

                 Summary: Feature Request: Return value from .oct after
octave_signal_caught
                 Project: GNU Octave
            Submitted by: hfriberg
            Submitted on: Fri 30 Sep 2011 08:51:23 AM GMT
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 3.2.3
        Operating System: Any

    _______________________________________________________

Details:

Many numerical algorithms are programmed work by converging
iteration-for-iteration toward the wanted solution. Lets says that such a
numerical algorithm had been implemented in a .oct-file for performance, and
that for some data the convergence is too slow (or the tolerance was too
optimistic). In this case the user would properbly loose patience and press
the CTRL+C combination to send a SIGNAL to octave prompting for termination.
Octave will set the 'octave_signal_caught' variable in quit.h to one, and the
.oct-file would have a chance to clean up variables before calling the
'OCTAVE_QUIT' macro also in quit.h. This macro will then throw an exception of
type 'octave_interrupt_exception', which is caught somewhere outside the
.oct-file. 

The problem with this approach is that there are no way to return the best
solution found so far, which becomes a real problem if you have spent hours
waiting for the result of the algorithm having stagnated just outside the
specfified tolerance. It is frustrating knowning that the solution may never
be able to converge any close, but yet cannot be retrieved.

Of course, the .oct file do not have to call the 'OCTAVE_QUIT' macro when it
detects the CTRL+C interruption. As the 'octave_signal_caught' variable is
volatile, we can just set it back to zero (as if nothing had happened) and
return a solution to the user. Unfortunately, this does not work well in
practice. I have looked at the embed.cc file in the pure-octave project which
calls the following function after having caught the
'octave_interrupt_exception' exception.

static void recover(void)
{
  unwind_protect::run_all ();
  can_interrupt = true;
  octave_interrupt_immediately = 0;
  octave_interrupt_state = 0;
  octave_signal_caught = 0;
  octave_exception_state = octave_no_exception;
  octave_restore_signal_mask ();
  octave_catch_interrupts ();
}


I am not sure if it is this simple, but I have noticed that the variable
'octave_interrupt_state' from quit.h increments by one each time CTRL+C is
pressed. That is, for each time we omit to call the 'OCTAVE_QUIT' macro, the
variable 'octave_interrupt_state' accumulates. This variable is not volatile
so it cannot be set from the .oct-file, and when it reaches a value of two,
the next key-combination CTRL+C kills Octave with the following message.

panic: Interrupt -- stopping myself...


So my feature request is this: 
Please make it possible to "recover" from an interruption, without having to
terminate by an exception. Maybe it is enough to make the
'octave_interrupt_state' volatile in quit.h, but I am unsure of this. 

Another possibility:
I have examined the behavior of the 'octave_interrupt_exception' exception
thrown from the .oct-file, and it seems that when control is returned to the
parent .m-file, the only code executed is the one put inside a
"unwind_protect_cleanup". However, setting return variables from here only
affects the local copies and are not carried over to the .m-file's parent. If
this worked, it would be possible to make second call to the .oct-file which
would do nothing but return the solution found in the previous call (saved in
global variables).




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?34438>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/