[Rcpp-devel] Thread handling

Christian Gunning xian at unm.edu
Wed Apr 27 02:19:42 CEST 2011

> As is, I?m able to return an argument such as a
> SEXP value from my function, and I can have it give feedback. However, if I
> do that before the thread finishes, I don?t know if there is a way to access
> it any more after the thread finishes. Likewise, if I were to wait until the
> thread finishes, then I might as well not call a thread. So what would be
> recommended as an Rcpp suggested mechanism for alerting users in R as to
> when threaded jobs finish?
> Thanks,
> Sean

I realize this might not be the best place for this, but here are some
quick notes on user feedback that might help other (new) Rcpp users --

1. If you just want to *print* a progress report to the console, both
std::cout and Rf_PrintValue should work just fine.  The first is
normal c++ semantics.  The second takes an SEXP and sends it to R for
printing (see R extensions manual 4.4.2 for details).  No idea how
this second one behaves with threading since, as Dirk pointed out, R
is single-threaded.

2. On a related aside -- if you want long-running tasks to be
interruptable, you must specifically request such. From a
single-threaded perspective, this is easy. Maybe this could generalize
for you -- if so, I'm curious to see. From the extensions manual,
section 6.12, Allowing interrupts:

"No port of R can be interrupted whilst running long computations in
compiled code, so programmers should make provision for the code to be
interrupted at suitable points by calling from C
#include <R_ext/Utils.h>
void R_CheckUserInterrupt(void);

My understanding is that, while R is single-threaded, your C++ code
can do whatever it wants while R is waiting for it to return, provided
there's a single point-of-return. So, #1 above isn't really a
callback, but careful use of stdout should at least give you a
progress bar...


A man, a plan, a cat, a ham, a yak, a yam, a hat, a canal – Panama!

More information about the Rcpp-devel mailing list