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

From: Prof Brian Ripley <>
Date: Wed 20 Sep 2006 - 05:32:27 GMT

On Tue, 19 Sep 2006, Henrik Bengtsson wrote:

> On 9/19/06, Prof Brian Ripley <> 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,        
Professor of Applied Statistics,
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________ mailing list
Received on Wed Sep 20 15:34:52 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Wed 20 Sep 2006 - 07:30:08 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.