Re: Working patch for FFTW 3.0.x and Nd FFT's

[John W. Eaton]

On 18-Feb-2004, Paul Kienzle <address@hidden> wrote:

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

OK, in the end, I went for a solution like the above.  Now we have

  crash_dumps_octave_core
  octave_core_file_limit
  octave_core_file_name
  octave_core_file_format

I suppose we could do away with crash_dumps_octave_core, but I'll
leave it for now.

The limit is specified in kilobytes and is only approximate because
the computation of the limit is based on the in-memory size of the
data, not the precise size of the data that is written to the file.
Also, the algorithm for limiting is just to see if the next element to
be saved would go beyond the limit, and if so, don't save it.  It
might be better to sort by size and save all the smallest variables
that will fit.  In any case, it seems OK to me.  If someone else wants
something better, they will have to write it.

Should Octave also attempt to save the history file when it aborts?
It's annoying to lose history if a crash occurs, but if we try to save
the history from the signal handler and that fails (not unlikely) then
we could lose the entire contents of the history file, not just the
entries for the current session.

jwe