[Octave-bug-tracker] [bug #52876] interrupt with <Ctrl> C does not terminate octave during pause

[Dan Sebald]

Follow-up Comment #5, bug #52876 (project octave):

Thanks for addressing this quickly, as I started digging into the issue and
would have kept going.  I basically printed debug statements to std::cerr
wherever there was octave_interrupt_state action.

I pulled the latest source and nothing has changed (an executing hunk of
script breaks out, but not the sleeping pause).


octave:4> for i=1:10e8;
> x=1;
> end
^C
octave:4> 
octave:4> pause()

octave:4> 


Perhaps I'm not testing this correctly, but likely a timer computation issue. 
(I can look debug on this end, if you like.)  

I read a lot of FIXME's near the octave_interrupt_state increments and tests. 
This awake/poll/octave_quit approach to dealing with signals isn't good, but I
understand it is the best that can be done right now.

My feeling is that Octave is a rather sophisticated interpretted computer
language and, as such, it really requires a sophisticated interrupt
system--one that is very solid and easy to use when it is debugged.  That is,
spend some time coming up with a scheme that programmers really don't have to
think too much about.  My initial thoughts on how to do that is Octave should
have its own stack management and (possibly) memory management.  Octave sort
of has the latter already.  What I mean by that is there should be

GLOBAL STACK
GLOBAL MEMORY
EXECUTION STACK
EXECUTION MEMORY

There must be some way in C to take control of the stack, e.g.,

https://stackoverflow.com/questions/1847053/how-to-get-address-of-base-stack-pointer

The idea is that before parsing and executing code, Octave would record the
current location of the call-stack.  When parsing, executing, Octave would put
any temporary heap variables (i.e., those that won't reside in global memory
when done) into it's own sort of local heap.  Some of those entries may go to
global memory (either immediately or eventually after the whole script has
executed successfully).  Then, if a SIGINT comes along, it's simply a matter
of stopping execution by rewinding the local call stack, freeing the local
heap and jumping back to the Octave command line.  No checking octave-quit, no
sleep/poll timers, etc.--fast and efficient.

    _______________________________________________________

Reply to this item at:

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

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