Interrupts (was Re: [Rd] X11 protocol errors ...)

[Luke Tierney]

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