bugGNU Octave - Bugs: bug #34438, Feature Request: Return value from...


bug #34438: Feature Request: Return value from .oct after octave_signal_caught

Submitter:  Henrik Alsing Friberg <hfriberg>
Submitted:  Fri 30 Sep 2011 08:51:23 AM UTC
Category:  Libraries Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Feature Request
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Fri 30 Sep 2011 08:51:23 AM UTC, original submission:  

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

Henrik Alsing Friberg <hfriberg>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by hfriberg (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-01-19 mtmiller CategoryNone Libraries
        Severity3 - Normal 1 - Wish
        Release3.2.3 dev

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code