[Rcpp-devel] Rcpp::exception + threads = disaster
kevinushey at gmail.com
Sat Feb 8 22:44:51 CET 2020
On Sat, Feb 8, 2020 at 12:52 PM Joshua N Pritikin <jpritikin at pobox.com> wrote:
> On Sat, Feb 08, 2020 at 03:47:49PM -0500, JJ Allaire wrote:
> > On Sat, Feb 8, 2020 at 3:45 PM Joshua N Pritikin
> > <jpritikin at pobox.com> wrote:
> > Sure, but does it *have* to be that way? It seems to me that
> > exceptions.h line 40,
> > rcpp_set_stack_trace(Shield<SEXP>(stack_trace()))
> > Not sure about whether this is indeed a mandatory constraint (I didn't
> > work on the stack trace bit).
> If I'm reading it correctly, rcpp_set_stack_trace(Shield<SEXP>(stack_trace()))
> will work equally well in either location. R can't introspect about
> the C++ stack; It must be saving the R call stack.
This is incorrect; Rcpp is trying to save the C++ call stack:
That call stack is saved as part of an R object that is later read and
re-attached to an R condition object at the top level:
In theory, we might be able to avoid the creation of an intermediate R
object when the exception is constructed -- patches are welcome. I'm
not sure why this data is stored within the R session rather than e.g.
as part of the exception object itself, but generally these sorts of
decisions are made for good reasons (e.g. complications with
As an aside, you could just use tfm::format() (bundled by Rcpp and
used by stop() and friends) to build your formatted strings and then
throw a regular C++ exception.
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
More information about the Rcpp-devel