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