[Rcpp-devel] Using Rcpp::Function in parallel with TBB mutex lock & a reference.

[Kumar MS]

Thank you very much for the clear answers, Dirk! They greatly help!

Cheers,
Kumar


On Sat, Feb 8, 2025 at 1:17 PM Dirk Eddelbuettel <edd at debian.org> wrote:

>
> On 7 February 2025 at 14:01, Kumar MS wrote:
> | Thank you Dirk. Your observation is correct. I am left with two
> questions. As
> | always, I appreciate your answers.
> |
> | 1. Except for this single step of calling an R function (model
> matrix-like
> | objects that are being created by an external library in R), all my other
> | computations are now implemented in C++ & thread friendly. Does this
> mean I
> | would have no other option but to go serial if I need to call R an
> function? Do
> | you have any alternative recommendations? I would really love to take
> advantage
> | of RcppParallel/TBB here, as I have heavily exploited RcppParallel to
> | parallelize everything else.
>
> Not to ruin your day (again) as I believe we have been over this a few
> times
> between here and your StackOverflow questions: Nomatter how much you want
> it
> to be possible you still cannot call back to R from the parallel code.
>
> | 2. Your RInside calculations in the Boost thread example are
> multi-threaded,
> | with a locking interface to RInside instance too. I wonder what makes
> that work
> | well without R reporting issues, while the TBB/rcppParallel
> implementation
> | taking a similar approach has trouble.
>
> RInside is not really a relevant example as it operates the other way
> around
> where you have a `main()` function and want to embed R.  What we do with
> Rcpp
> is typically a running R process from which we call extensions. Not the
> same.
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20250210/bf56b1d2/attachment.htm>