[Rd] "try"ing to understand condition handling (interrupts)

[Luke Tierney]

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