[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
>