On 22-Aug-2001, Luke Tierney <luke@nokomis.stat.umn.edu> 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 | safe). 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 things. 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 QUIT; 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. jwe
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: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._