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


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

Submitted by:  Henrik Alsing Friberg <hfriberg>
Submitted on:  Fri 30 Sep 2011 08:51:23 AM UTC  
Category: LibrariesSeverity: 1 - Wish
Priority: 5 - NormalItem Group: Feature Request
Status: NoneAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


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.

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.

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 File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 19 Jan 2014 10:53:06 PM UTCmtmillerCategoryNone=>Libraries
      Severity3 - Normal=>1 - Wish

    Back to the top

    Powered by Savane 3.1-cleanup1