[Rd] wishlist --- menu entry [Rgui] misc --- stop current computation

[Prof Brian Ripley]

On Tue, 19 Sep 2006, Henrik Bengtsson wrote:

> On 9/19/06, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
>> On Tue, 19 Sep 2006, Kjetil Halvorsen wrote:
>> 
>> > This is from R-2.4.0alpha on windows XP, downloaded from CRAN yesterday.
>> >
>> > I did
>> > update.packages(destdir= ..., ask=FALSE,checkBuilt=TRUE)
>> >
>> > which took quite a long time (as.expected). When the internet cafe
>> > had to close, I had to stop the downloading, but the menu item
>> > misc --- stop current computation only stopped the current download,
>> > and then R imeadiaetely continued whit the next in the waitin list, so I 
>> had
>> > to kill
>> > R. I  would be nice if this could be corrected so it really
>> > stopped all the waiting computastion!
>> 
>> As it does what it says, it cannot be 'corrected' to do something else.
>> I usually find hitting Ctrl-C (or ESC in Rgui) a few times breaks out
>> here.
>> 
>> The issue is that update.packages (or more precisely download.packages)
>> has a loop of try() constructs, and those are trapping interrupts.
>> I don't think there is any way to distinguish those from other internal
>> errors.  In any case, it is a somewhat delicate question as to what you
>> want: do you want pending on.exit() actions done, for example?
>
> Without digging into the update.packages() et al code, wouldn't a
> distinction between 'error' and 'interrupt' using tryCatch() rather
> than try() solve this?  ...assuming "stop current computation" signals
> some kind of interrupt.

Only to change the design intention for a particular piece of code. Here 
the design intention was to abort just the current download (which can be 
quite useful if it hangs, and allows other packages in the set to be 
installed).  And that only if the interrupt is handled by R, rather than 
by a process invoked by system(), which is possible behaviour in 
download.packages depending on the options. Although it is hard to break 
this particular loop on RGui (harder than I thought as the progress bar 
shifts focus), it does not seem a common enough problem to try to solve on 
its own, and in particular not to change the design intention.

I took the request to be general, and retrospective: 'I have a computation 
running, and I have now decided I want to stop it completely and return to 
the top level'.  That's a reasonable request, especially to those who 
would like to save earlier work in the session (and on Unix we have 
SIGUSR1 to kill the session and save the workspace).  There is only one 
type of interrupt internally in R, and no way that I know of to override 
code-specific interrupt handling,

To do that it looks like we need different classes of interrupts.  Unix 
has several signals for this purpose, but Windows does not.  It's messy 
(not all Unices are the same), but I have in the past wondered about using 
(some of) SIGINT, SIGKILL, SIGTERM and SIGSTOP to do different things, and 
we could fake something similar under Windows.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595