[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working patch for FFTW 3.0.x and Nd FFT's
From: |
Paul Kienzle |
Subject: |
Re: Working patch for FFTW 3.0.x and Nd FFT's |
Date: |
Wed, 18 Feb 2004 22:02:13 -0500 |
When I was reading up on it before, I understood that
you should not be doing blocking operations in a
signal handler. At the very least, you should be
minimizing them.
How about:
if (octave_interrupt_state == 2 && interactive) {
std::cerr << "Press Ctrl-C again to abort" << std::endl;
}
if (octave_interrupt_state >= 3) {
my_friendly_exit(sys_siglist[sig],sig,true);
}
With ulimit, I don't see any reason not to save the workspace.
I would still be tempted to do something less drastic,
such as put a set jump before each binary function and
warn the user that the system may have leaked resources
and may be unstable.
Paul Kienzle
address@hidden
On Feb 18, 2004, at 3:50 PM, John W. Eaton wrote:
static RETSIGTYPE
-#if defined (ACK_USES_SIG) || defined (REINSTALL_USES_SIG)
sigint_handler (int sig)
-#else
-sigint_handler (int)
-#endif
{
MAYBE_ACK_SIGNAL (sig);
@@ -334,7 +333,47 @@
if (octave_interrupt_immediately)
octave_jump_to_enclosing_context ();
else
- octave_interrupt_state = 1;
+ {
+ octave_interrupt_state++;
+
+ if (interactive)
+ {
+ if (octave_interrupt_state > 3)
+ {
+ // XXX FIXME XXX -- might want to attempt to flush
+ // any pending input first...
+
+ std::cerr << "abort [y/N]? ";
+
+ int c = octave_kbhit ();
+
+ std::cerr << static_cast<char> (c) << std::endl;
+
+ if (c == 'y' || c == 'Y')
+ {
+ std::cerr << "save top-level workspace [y/N]? ";
+
+ c = octave_kbhit ();
+
+ std::cerr << static_cast<char> (c) << std::endl;
+
+ my_friendly_exit (sys_siglist[sig], sig,
+ (c == 'y' || c == 'Y'));
+ }
+ else
+ {
+ // We will still eventually interrupt and jump to
+ // the top level even if no additional interrupts
+ // happen, but we will have to wait until it is
+ // safe to do so. It will take 3 more
+ // consecutive interrupts before we offer to
+ // abort again.
+
+ octave_interrupt_state = 1;
+ }
+ }
+ }
+ }
}
- Working patch for FFTW 3.0.x and Nd FFT's, (continued)
- Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/16
- Re: Working patch for FFTW 3.0.x and Nd FFT's, David Bateman, 2004/02/17
- Re: Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/17
- Re: Working patch for FFTW 3.0.x and Nd FFT's, David Bateman, 2004/02/17
- Re: Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/17
- Re: Working patch for FFTW 3.0.x and Nd FFT's, Paul Kienzle, 2004/02/17
- Re: Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, Dmitri A. Sergatskov, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, Dmitri A. Sergatskov, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's,
Paul Kienzle <=
- Re: Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, Paul Kienzle, 2004/02/19
- Re: Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/20
- Re: Working patch for FFTW 3.0.x and Nd FFT's, David Bateman, 2004/02/18
Message not available
- Message not available
- Re: Working patch for FFTW 3.0.x and Nd FFT's, Daniel J Sebald, 2004/02/17
- Re: Working patch for FFTW 3.0.x and Nd FFT's, David Bateman, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, Daniel J Sebald, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, David Bateman, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, Dmitri A. Sergatskov, 2004/02/18
- Re: Working patch for FFTW 3.0.x and Nd FFT's, John W. Eaton, 2004/02/18