On 21 Sep 2017, at 17:53, Tomas Kalibera <tomas.kalibera at gmail.com> wrote:
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