"try"ing to understand condition handling (interrupts)
On Tue, 20 Feb 2007, Ross Boylan wrote:
[resequencing and deleting for clarity] On Tue, Feb 20, 2007 at 01:15:25PM -0600, Luke Tierney wrote:
On Tue, 20 Feb 2007, Ross Boylan wrote:
P.S. Is there any mechanism that would allow one to trap an interrupt, like a ctl-C, so that if the user hit ctl-C some state would be changed but execution would then continue where it was? I have in mind the ctl-C handler setting a "time to finish up" flag which the maini code checks from time to time.
On Tue, Feb 20, 2007 at 07:35:51AM +0000, Prof Brian Ripley wrote:
...
I quess 'ctl-C' is your private abbreviation for 'control C' (and not a
[yes, ctl-C = control C, RB]
type of cancer): that generates an interrrupt in most (but not all) R ports. Where it does, you can set up interrupt handlers (as the help page said)
My P.S. concerned whether the code that was interrupted could continue from the point of interruption. As far as I can tell from ?tryCatch there is not,
Currently interrupts cannot be handled in a way that allows them to continue at the point of interruption. On some platforms that is not possible in all cases, and coming close to it is very difficult. So for all practical purposes only tryCatch is currently useful for interrupt handling. At some point disabling interrupts will be possible from the R level but currently I believe it is not. Best, luke
I had suspected that, since R is not thread-safe, handling asynchronous events might be challenging.
This has nothing to do with thread safety. It has everything to do with what is safe to do within signal handlers on the one hand and OS specific variations on what happens when signals interrupt a system call on the other.
I tried the following experiment on Linux:
h<-function(e) print("Got You!")
f<-function(n, delay) for (i in seq(n)) {Sys.sleep(delay); print(i)}
withCallingHandlers(f(7,1), interrupt=h)
[1] 1 [1] "Got You!" So in this case the withCallingHandlers acts like a tryCatch, in that control does not return to the point of interruption. However, sys.calls within h does show where things were just before the interrupt:
h<-function(e) {print("Got You!"); print(sys.calls());}
withCallingHandlers(f(7,1), interrupt=h)
[1] 1
[1] 2
[1] 3
[1] "Got You!"
[[1]]
withCallingHandlers(f(7, 1), interrupt = h)
[[2]]
f(7, 1)
[[3]]
Sys.sleep(delay)
[[4]]
function (e)
{
print("Got You!")
print(sys.calls())
}(list())
Experiments like this are useful but don't expect results you get to be reliable in the future. What the call stack as shown by sys.xyz looks like in particular at handling time may change (probably not much for calling handlers but most likely for exiting ones). Best, luke
Ross
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke at stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu