On 01/02/2010 10:26 PM, Whit Armstrong wrote:
Romain,
Is the use of UNPROTECT_PTR discouraged? I wonder why you haven't
considered using it instead.
that's not what I said. It just felt not as easy to use as just grab a
SEXP and say R_PreserveObject( x ) and then later R_ReleaseObject.
I did not mean to discourage people from using it. It is probably very
stable indeed since it is used all over the place in the parser, and
since the parser is probably the most used code in the R source tree, we
would know if it did not work properly.
I have a similar project that uses a ref counting scheme and handles
the deletion of the shared object with UNPROTECT_PTR. This method has
been working fine, but if there are reasons I should not be using it,
I would certainly like to know.
From memory.c: /* "unprotect_ptr" remove pointer from somewhere in R_PPStack */
The code is very simple, it just walks backwards down the list until
it hits your object. Unless you are adding an obscene number of items
to the protection stack in a given call, finding your object should be
very fast.
My example is here:
http://github.com/armstrtw/rabstraction/blob/master/R.backend.hpp
>
template<SEXPTYPE RTYPE>
Rbackend<RTYPE>::~Rbackend() {
if(release_data_) {
if(R_object_!=R_NilValue) {
UNPROTECT_PTR(R_object_);
}
}
}
Thanks. I'll have a look.
I still think all these Rcpp projects should come together some day.
Dirk and I talked about combining about two years ago, but "real" work
got it the way. I'll ping you off list for a follow up.
Dirk is proving very cooperative and the "Rcpp" package is under a lot
of changes currently in its new Rcpp namespace, while keeping the
current interface.
Our main class is Rcpp::RObject that wraps any SEXP into a C++ object
that basically R_PreserveObject when it is created, and R_ReleaseObject
when the object is destroyed.
deriving from "RObject", we have "Environment" to deal specifically with
environments (ENVSXP) , "Symbol" to deal with symbols (SYMSXP),
"Language" for calls (LANGSXP) and the template XPTr for external
pointers. The rest (vectors, functions, ...) will follow.
I'd suggest using the Rcpp mailing list for a follow up.
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
-Whit
On Sat, Jan 2, 2010 at 12:24 PM, Romain Francois
<romain.franc...@dbmail.com> wrote:
On 01/02/2010 06:01 PM, Simon Urbanek wrote:
On Jan 2, 2010, at 5:07 AM, Romain Francois wrote:
Hello,
We are currently making lots of changes to Rcpp (see the open Rcpp
mailing list if interested [1] in the details).
We are now using [2] R_PreserveObject and R_ReleaseObject to manage
garbage collection instead of the PROTECT/UNPROTECT dance. This seems to
work well, but I was wondering if there was documentation about it.
I don't think so - the only documentation is the comment in the source.
Fair enough. FWIW, some mention of it in the R-ints or R-exts could be
valuable.
In particular, if we preserve the same SEXP twice (or more), should we
implement some sort of reference counting ?
Preserve/Release are for managing objects that are supposed to survive
past the call and are not tied to any other R object. PROTECT/UNPROTECT are
for temporary preservation within a call.
Although you're right that Preserve/Release is effectively implemented as
a stack at the moment it is not stated explicitly anywhere (this goes all
the way back to R 0.64 so chances are that only Ross can comment..).
However, for practical purposes it would be potentially dangerous to have it
work like a flag because you can simply never know whether the same object
was not already registered by some other code.
Reading the source (below, from memory.c) I think not, but some
confirmation would help.
void R_PreserveObject(SEXP object)
{
R_PreciousList = CONS(object, R_PreciousList);
}
static SEXP RecursiveRelease(SEXP object, SEXP list)
{
if (!isNull(list)) {
if (object == CAR(list))
return CDR(list);
else
CDR(list) = RecursiveRelease(object, CDR(list));
}
return list;
}
void R_ReleaseObject(SEXP object)
{
R_PreciousList = RecursiveRelease(object, R_PreciousList);
}
I'd also be interested if there is some ideas on the relative efficiency
of the preserve/release mechanism compared to PROTECT/UNPROTECT.
PROTECT/UNPROTECT is more efficient because all it does is a pointer
assignment -- Preserve has to allocate new node and fill it with all parts.
On release the extra node is still floating in the GC pool etc.
Normally there is not really a question of choice - within a call you want
to use PROTET/UNPROTECT and for anything else you simply cannot use it so
you have to use Preserve/Release. As a side note Preserve/Release is merely
a convenience call, it is often more efficient to simply assign the object
to another object you have control of (which is all Preserve really does).
Cheers,
Simon
Thanks for this advice. This will make it easier to do the bookkeeping of
how many objects we preserve, etc ...
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/IW9B : C++ exceptions at the R level
|- http://tr.im/IlMh : CPP package: exposing C++ objects
`- http://tr.im/HlX9 : new package : bibtex
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
