[Rd] Checking for user interrupt in a .C() call without without triggering a non-local exit.

Luke Tierney luke at stat.uiowa.edu
Tue Feb 27 18:37:08 CET 2007


On Mon, 26 Feb 2007, Pavel N. Krivitsky wrote:

> Hi,
>
> An R package on which I am working makes a series of very
> computationally-intensive and complex .C() calls, that I would like to
> make interruptible. However, calling R_CheckUserInterrupt() causes a
> non-local exit, so the memory allocated by malloc() is never freed. The
> way the code is structured, it might not be practical to replace all the
> malloc() calls with R_alloc() calls.
>
> The question is, can I somehow detect a user interrupt and handle it
> gracefully in my own code? A similar question was posed a few months ago
> ( http://tolstoy.newcastle.edu.au/R/devel/06/08/6415.html ), but didn't
> get any response. Has anything changed since?

Not really.  There is an internal mechanism for registering C level
on.exit routines but this is not in a form that can be made public as
it would tie down implementation decisions too much.  It is principle
possible to build something around R_ToplevelExec, but that is not at
this point part of the public API and so is subject to change.  We
might consider providing something along these lines after 2.5 is
released.  A tricky issues is that while checking for interrupts is
cheap on standard Unix setups where interrupts arrive as signals, it
isn't in GUI setups where event processing is needed to detect whether
a user interrupt action has occurred (and that checking could cause
errors and non-local exits).

Best,

luke


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



More information about the R-devel mailing list