octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: signal handling


From: Paul Kienzle
Subject: Re: signal handling
Date: Thu, 14 Nov 2002 21:28:58 -0500
User-agent: Mutt/1.2.5.1i

On Thu, Nov 14, 2002 at 03:59:45PM -0600, John W. Eaton wrote:
> On 14-Nov-2002, Paul Kienzle <address@hidden> wrote:
> 
> | Can we have a debug_on_interrupt flag so that octave will stop at the
> | next statement?  This can be useful if you have a long running process.
> | Hit Ctrl-C, see where it has got to, then continue.  
> 
> Sure, this seems like a reasonable feature.
> 
> | One problem I see is that you don't know whether the last line ran to
> | completion or if it was interrupted within an external function.  In a
> | patch I sent earlier, the first interrupt would set a flag saying stop at
> | the next statement, but if the user got bored waiting they could hit ctrl-C
> | again which would see that the flag had been set and abort to the top
> | level.
> 
> OK, so this "double interrupt" will only be required when
> debug_on_interrupt is true and we are inside foreign code that would
> normally jump out of the signal handler, correct?

__long__ running foreign code.  Short running foreign code (e.g., a small
matrix multiply) will quickly get to the next statement and the debugger
will pick it up before the user has a chance to press Ctrl-C twice.  

It might be nice to let the user know which foreign function is active when
Ctrl-C is pressed the first time, but I/O during signal handling sounds
like a bad idea.

> 
> jwe
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]