Interrupts (was Re: [Rd] X11 protocol errors ...)
John W. Eaton
Wed, 22 Aug 2001 21:56:33 -0500
On 22-Aug-2001, Luke Tierney <firstname.lastname@example.org> wrote:
| We will I think have to come up with a cleaner model for very
| selectively enabling interrupt processing, perhaps with some
| integration with the external function registration mechanism Duncan
| added recently (e.g. marking a function as one where LONGJMP's are
FWIW, Octave doesn't do this correctly either, it just does a longjmp,
same as R, which can result in leaking memory, and possibly other bad
The way Bash handles this is to only set a flag in the handler for
SIGINT, then at safe places in the code, there are
statements. These are macros that expand to some code that may
longjump somewhere depending on the interrupt state. This method
avoids the problems of jumping out of the signal handler, which may
result in memory leaks or inconsistencies in global state. The hard
part is inserting the (many!) QUIT statements, though it is probably
somewhat easier if this type of choice is made early on in the life of
the program instead of late.
I only mention Bash because it is a program that is expected to
handle a lot of interrupts without leaking memory or crashing, and
seems to do so reasonably well.
Packages like R and Octave also have to be able to handle interrupts
in calls Fortran or C code that may run for a long time, and which
cannot be modified (at least not easily) to add the equivalent QUIT
calls. I'm not sure what the right solution is for cases like that.
www.octave.org | Unfortunately we were hoplessly optimistic in 1954
www.che.wisc.edu/~jwe | about the problems of debugging FORTRAN programs.
| -- J. Backus
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: email@example.com