Martin wrote:
Just this morning, I found (again!, we had something close to this before) the following related bugous behavior : After interrupting a plot (which would have taken a few minutes and was "wrong" anyway), starting another plot, interrupting again [with C-c], and maybe the same once more, R started just giving a ">" prompt but did not react any further at all. (C-c would return the prompt, but no other reaction was possible) Only killing the R process helped. I may try to reproduce more exactly later today.
I'm surprised we don't get more of these sorts of things on UNIX. Our current UNIX interrupt handling approach takes an immediate LONGJMP out of the signal handler no matter where the signal occurs (except for two places where signals are suspended). Any place where an invariant is temporarily broken, any place where an assignment is not yet complete, is a potential trouble spot. I've been meaning to raise this issue at some point: I think we will need to eventually spend some time re-examining how we want to handle interrupts. Right now on Windows/Mac interrupts are only processed at special points in the evaluation process, which is a bit restrictive (but perhaps unavoidable due to OS limitations). On UNIX on the other hand we LONGJUMP out of the signal handler except for the very few places where the signal gets masked temporarily (GC and one place in graphics I believe). The UNIX approach is much too loose even now, and it becomes even more untenable if we add any kind of threading support. 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). We will also need some means of controlling interrupt behaviour from R, such as having some sort of without.interrupts and with.interrupts functions to be able to program reliable interaction with interrupts at the R level. (Another sort of thing we might consider is suspending interrupts during on.exit processing.) It's a farily big can of worms, and probably not urgent for now, but we will need to look at it eventually. luke
Luke Tierney University of Minnesota Phone: 612-625-7843 School of Statistics Fax: 612-624-8868 313 Ford Hall, 224 Church St. S.E. email: luke@stat.umn.edu Minneapolis, MN 55455 USA WWW: http://www.stat.umn.edu -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._