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 <e...@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 | e...@debian.org >
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
