[Rd] internal copying in R (soon to be released R-3.1.0
Jens Oehlschlägel
Jens.Oehlschlaegel at truecluster.com
Mon Mar 3 21:35:27 CET 2014
Thanks for answering Simon,
> None, there is no concept of "shared" memory at R level. You seem to
be mixing C level API specifics and the R language. In the former
duplicate() creates a new copy.
I take this as evidence that calling duplicate() is the only way to make
sure I have a non-shared object.
> Assuming that you are talking about the C API, please consider
reading about the concepts involved. .Call() doesn't set named to 2 at
all - it passes whatever object is passed so it is the C code's
responsibility to handle incoming objects according to the desired
semantics (see the previous post here).
Well, I did read, for example "Writing R Extensions" (Version 3.1.0
Under development (2014-02-28)) chapter "5.9.10 Named objects and
copying" which says "Currently all arguments to a .Call call will have
NAMED set to 2, and so users must assume that they need to be duplicated
before alteration." This is consistent with the observation of my test
code: that NAMED() in .Call always returns 2. And that a .Call doing
pure read access will trigger some delay most likely due to a full
vector copy is a sign of .Call not only setting NAMED to 2 but also not
resetting it once .Call terminates.
So what is needed to find NAMED(SEXP argument) < 2 during .Call?
Kind regards
Jens
More information about the R-devel
mailing list