[Rd] calling R API functions after engine shutdown
Tomas Kalibera
tomas.kalibera at gmail.com
Thu Sep 21 17:53:31 CEST 2017
Calling R_ReleaseObject in a C++ destructor is not reliable - it can be
bypassed by a non-local return, such as an error. Generally in R one
cannot use C++ destructors reliably for anything that the R runtime
wouldn't do on its own in case of a non-local return.
A destructor that calls just UNPROTECT, in a way that balances out the
protection stack (e.g. Rcpp Shield), is safe because R runtime balances
the protection stack on non-local return. Destructors used in code that
will never call into any R API (such as in a third party library) are
safe, because the R runtime could not do non-local return. All other
destructors are a problem.
UNPROTECT will work even during R shutdown.
In some cases cleanup code that would be put in C++ destructors, if they
were safe with R, can instead be put into R finalizers.
Tomas
On 09/21/2017 04:41 PM, Lukas Stadler wrote:
> Hi!
>
> We’ve recently come across an example where a package (minqa) creates an Rcpp Function object in a static variable.
> This causes R_ReleaseObject to be called by the destructor at a very late point in time - as part of the system exit function:
>
> static Function cf("c");
>
> I’m wondering if that is considered to be “safe”?
> Is the R engine supposed to stay in a state where calls to API functions are valid, even after it has shut down?
> It probably only ever happens with the ReleaseObject function, but even that could cause problems, e.g., with more elaborate refcounting schemes.
>
> - Lukas
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
More information about the R-devel
mailing list