[Rcpp-devel] Rcpp::exception + threads = disaster

Kevin Ushey 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
> >    <[1]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
cross-module exceptions).

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
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel

More information about the Rcpp-devel mailing list