R devel - Apr 2011 - Interrupting C++ code execution

Hello,

I am writing an R interface for one of my C++ programs. The computations 
in C++ are very time consuming (several hours), so the user needs to be 
able to interrupt them. Currently, the only way I found to do so is 
calling R_CheckUserInterrupt() frequently. Unfortunately, there are 
several problems with that:

1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no 
possibility to exit my code gracefully. In particular, I suppose that 
objects created on the heap (e.g., STL containers) are not destructed 
properly.

2. Calling R_CheckUserInterrupt() within a parallel OpenMP loop causes 
memory corruptions. Even if I do so within a critical section, it 
usually results in segfaults, crashes, or invalid variable contents 
afterwards. I suppose this is due to the threads not being destroyed 
properly. Since most of the time critical computations are done in 
parallel, this means I can hardly interrupt anything.

Having a function similar to R_CheckUserInterrupt() but returning a 
boolean variable (has an interrupt occurred or not?) would solve these 
problems. Is there a way to find out about user interrupt requests (the 
user pressing ctrl+c or maybe a different set of keys) without 
interrupting immediately?

I would appreciate your advice on this topic.


Best regards,
Peter

On Apr 25, 2011, at 5:22 AM, schattenpflanze at arcor.de wrote:
> Hello,
> 
> I am writing an R interface for one of my C++ programs. The computations in
C++ are very time consuming (several hours), so the user needs to be able to
interrupt them. Currently, the only way I found to do so is calling
R_CheckUserInterrupt() frequently. Unfortunately, there are several problems
with that:
> 
> 1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no
possibility to exit my code gracefully. In particular, I suppose that objects
created on the heap (e.g., STL containers) are not destructed properly.
> 
In general, you're responsible for the cleanup. See R-devel archives for
discussion on the interactions of C++ and R error handling. Generally, you
should not use local objects and you should use on.exit to make sure you clean
up.

> 2. Calling R_CheckUserInterrupt() within a parallel OpenMP loop causes
memory corruptions. Even if I do so within a critical section, it usually
results in segfaults, crashes, or invalid variable contents afterwards. I
suppose this is due to the threads not being destroyed properly. Since most of
the time critical computations are done in parallel, this means I can hardly
interrupt anything.
> 
As you know R is not thread-safe so you cannot call any R API from a thread -
including OMP threads - so obviously you can't call R_CheckUserInterrupt().
Since you're using threads the safe way is to perform your computations on a
separate thread and let R handle events so that you can abort your computation
thread as part of on.exit.

> Having a function similar to R_CheckUserInterrupt() but returning a boolean
variable (has an interrupt occurred or not?) would solve these problems. Is
there a way to find out about user interrupt requests (the user pressing ctrl+c
or maybe a different set of keys) without interrupting immediately?
> 
Checking for interrupts may involve running the OS event loop (to allow the user
to interact with R) and thus is not guaranteed to return. There is no general
solution - if you're worried only about your, local code, then on unix, for
example, you could use custom signal handlers to set a flag and co-operatively
interrupt your program. On Windows there is the UserBreak flag which can be set
by a separate thread and thus you may check on it. That said, all this is very
much platform-specific.

Cheers,
Simon

Peter,

On 25/04/11 10:22, schattenpflanze at arcor.de wrote:
> 1. Calling R_CheckUserInterrupt() interrupts immediately, so I have no
> possibility to exit my code gracefully. In particular, I suppose that
> objects created on the heap (e.g., STL containers) are not destructed
> properly.
Sorry not to have seen this thread sooner.

You may like to give CXXR a try 
(http://www.cs.kent.ac.uk/projects/cxxr/).  In CXXR the R interpreter is 
written in C++, and a user interrupt is handled by throwing a C++ 
exception, so the stack is unwound in an orderly fashion, destructors 
are invoked, etc.

However, it's fair to say that in using CXXR with a multi-threaded 
program you'll be on the bleeding edge...

Andrew

Andrew,
> You may like to give CXXR a try 
> (http://www.cs.kent.ac.uk/projects/cxxr/).  In CXXR the R interpreter is 
> written in C++, and a user interrupt is handled by throwing a C++ 
> exception, so the stack is unwound in an orderly fashion, destructors 
> are invoked, etc.
Thank you for this suggestion. CXXR is a very interesting project!

For my current project, however, I aim at distributing the program to
other R users on pre-installed cluster nodes. Thus, I have no choice
with respect to the underlying R interpreter.

Best regards,
Peter