[Rd] Transferring ownership of R-managed buffer
tkeitt at utexas.edu
Wed Mar 29 20:36:16 CEST 2017
On Wed, Mar 29, 2017 at 1:04 PM, Hervé Pagès <hpages at fredhutch.org> wrote:
> Hi Tim,
> On 03/29/2017 08:24 AM, Tim Keitt wrote:
>> I have a use case where I would like to create an SEXP around an existing
>> buffer that is managed by R, thus avoiding a copy operation.
> What to you mean exactly by "an existing buffer managed by R"?
Not allocated from the general heap, but rather allocated using R's
allocator and therefore returnable (hypothesis!) to the R interpreter as a
vector (not external pointer) without a copy operation.
> If I have
>> something like:
>> void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n)));
>> ... additional maniupulation ...
>> SEXP x = somefunc(SXPTYPE, n, p); // ????
>> Is there a "placement" constructor available?
> What's a "placement" constructor?
Function that constructs an object using previously allocated memory (for
example provided by a 3rd party library). In some cases, responsibility for
further management of the buffer is transferred to the new object.
> (I have arranged for the
>> corresponding UNPROTECT.) I've looked at and experimented with R_allocator
>> and allocVector3, but can't quite get it right. I know this is odd, but it
>> makes sense for my use case.
> Not sure I follow what you are trying to do. Note that an SEXP is a
> pointer to a C struct called SEXPREC. I think that trying to point an
> SEXPREC struct to data pointed to by an existing SEXPREC struct is very
> likely to lead to a disaster.
Possibly (although that is not what I am proposing). I'm still trying to
grok where the state resides (all in the SEXPREC or between that and the
> Note that if the existing buffer managed by R is an SEXP (e.g. b) and
> your code has access to this SEXP then you don't need to create another
> SEXP around its data. Since SEXPs are pointers doing
> SEXP x = b;
> is fine and doesn't generate any copy.
The buffer in this case might be resized and reallocated and the original
SEXP will have gone out of scope.
> And if your code only has access to a "naked" pointer to the buffer
> managed by R (e.g. to RAW(b) is the buffer is actually in an SEXP)
> then why would you need to wrap it inside an SEXP?
I'm working with 3rd party structures that can work with a pointer and
buffer length, but cannot track the original SEXP. I just need to construct
an SEXP (SEXPREC) and point it at the buffer, set the vector length and
data type. I was checking to see if there is an API for that (and that wont
interfere with Rcpp declarations as it pulls in parts of Rinternals.h, but
as far as I can tell, not the parts that I need to work with SEXPRECs at a
>> Thanks for any pointers.
>> [[alternative HTML version deleted]]
>> R-devel at r-project.org mailing list
> Hervé Pagès
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
> E-mail: hpages at fredhutch.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
[[alternative HTML version deleted]]
More information about the R-devel