[Rcpp-devel] Thread handling

[Steve Lianoglou]

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

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

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