Apologies, I am resending this because my emails seem to go in HTML form.
Hello,
This is a question that probably reveals my lack of understanding.
In a C function (call it cfunc), i created a SEXP, called S, and then
called R_PreserveObject on S.
I returned the SEXP to the calling R function (call it rfunc). Note, I
didn't call
R_ReleaseObject on S.
v <- .Call("cfunc")
So, are the following statements correct
1. S is 'doubly' protected from the GC by being associated both with 'v'
and because it has been added to the precious list (via a call to
R_PreserveObject without ReleaseObject being called)
2. I have another C function called cfunc2. In cfunc2, I call
R_ReleaseObject on S. S , however, is still protected from the GC, because
it is associated with 'v'
Is (1) and (2) correct?
I have not used R_protect/unprotect, because if I return from cfunc without
the equivalent number of unprotects, i get 'unbalanced stack' warnings. I'd
rather not have to worry about that because i intend to balance it later.
Regards
Saptarshi
There was a follow up in a subsequent email
Hello,
However, I do need some sort of protection.
(pseudo code)
SEXP a = Rf_allocVector(STRSXP,....)
protect a
for i = 1 to length of vector
SET_STRING_ELT(a,i, Rf_mkChar(...))
end
unprotect a
return a
I _need _that protect because in the for loop i also call some R functions
and need the object 'a' to be protected.
However, as I pointed out,
1. I replaced protect by PreserveObject
2. remove the unprotect word
I can guarantee, that some time later ReleaseObject will be called on 'a'.
So ultimately, whether this good design or not, the question remains,
given that 'a' is the in precious list, and 'a' is assigned to 'v', if
ReleaseObject is called on 'a', will 'a 'still be assigned to 'v' and
therefore not get GC'd.
In rudimentary tests, it doesn't appear to cause seg faults. But is it safe?
Cheers
Thanks
Saptarshi
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
