[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...
hth,
christian
--
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