Skip to content

[Rcpp-devel] Thread handling

4 messages · Steve Lianoglou, Dirk Eddelbuettel, Christian Gunning

#
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
#
Hi,

We kind of lost context of the original post, but:
On Tue, Apr 26, 2011 at 8:19 PM, Christian Gunning <xian at unm.edu> wrote:
Just to clarify the original intent -- the impression I got from the
OP is that he actually wanted to fire off a thread to run in the
background and have the user continue to use R while the background
process finishes, so ... he doesn't want R to wait for it to return.

I'm not an R-internals/plumbing guru, but if I had to guess, I'd say
that this is an "out of bounds" use case and I'm guessing will be
painful (impossible(?)) to get working as the OP intended ... I'd be
happy to be proven wrong, though.

I'm not sure what a suitable workaround would be -- I wonder if the
C(++) code you call down into can spawn a thread that then uses
RInside to fire up its own R process, configure it w/ the appropriate
vars/data, run the job in that single threaded R and just save the
results to some predertimed data file (not sure if that's the right
use case for RInside, either, I'm guessing) -- all the while control
will be returned to the users running R workspace.

At that point, though, maybe you'd just make a command line wrapper to
run your job from the shell and forget about invoking background
processes from within R altogether.

Just thinking out loud ..

-steve
#
On 26 April 2011 at 21:41, Steve Lianoglou wrote:
| We kind of lost context of the original post, but:

Did we?
| On Tue, Apr 26, 2011 at 8:19 PM, Christian Gunning <xian at unm.edu> wrote:
| Just to clarify the original intent -- the impression I got from the
| OP is that he actually wanted to fire off a thread to run in the
| background and have the user continue to use R while the background
| process finishes, so ... he doesn't want R to wait for it to return.
| 
| I'm not an R-internals/plumbing guru, but if I had to guess, I'd say
| that this is an "out of bounds" use case and I'm guessing will be
| painful (impossible(?)) to get working as the OP intended ... I'd be
| happy to be proven wrong, though.
| 
| I'm not sure what a suitable workaround would be -- I wonder if the
| C(++) code you call down into can spawn a thread that then uses
| RInside to fire up its own R process, configure it w/ the appropriate
| vars/data, run the job in that single threaded R and just save the
| results to some predertimed data file (not sure if that's the right
| use case for RInside, either, I'm guessing) -- all the while control
| will be returned to the users running R workspace.
| 
| At that point, though, maybe you'd just make a command line wrapper to
| run your job from the shell and forget about invoking background
| processes from within R altogether.
| 
| Just thinking out loud ..

Christian actually put it well:

a) R is single-threaded

b) You can leave R and start multi-threaded code at a well defined entry
point.

c) You can do your multithreaded work. I would recommend not to call R at
this point.

d) When done with multithreaded code, return to R and its control flow there.

That is a simple model, and it should work. 

Dirk
 
| -steve
| 
| -- 
| Steve Lianoglou
| Graduate Student: Computational Systems Biology
| ?| Memorial Sloan-Kettering Cancer Center
| ?| Weill Medical College of Cornell University
| Contact Info: http://cbio.mskcc.org/~lianos/contact
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
#
Just to clarify/reiterate (simplicity aside!) --
I was thinking about Steve's comments of RInside-with-Rcpp-within-R as
an interesting route to MPI, played with it for a while, and finally
came across this:

https://lists.r-forge.r-project.org/pipermail/rcpp-devel/2010-June/000767.html

At present RInside explicitly _forbids_ multiple invocations, and to
the best of my understanding this includes invocation from within an
Rcpp function within R.

-xian