From Jens.Oehlschlaegel at truecluster.com  Mon Mar  3 21:35:27 2014
From: Jens.Oehlschlaegel at truecluster.com (=?ISO-8859-1?Q?Jens_Oehlschl=E4gel?=)
Date: Mon, 03 Mar 2014 21:35:27 +0100
Subject: [Rd] internal copying in R (soon to be released R-3.1.0
In-Reply-To: <E4137A27-9188-4932-891E-7451ACEDC7C2@r-project.org>
References: <53136C77.2010603@truecluster.com>
	<E4137A27-9188-4932-891E-7451ACEDC7C2@r-project.org>
Message-ID: <5314E78F.4030804@truecluster.com>

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



[Rd] internal copying in R (soon to be released R-3.1.0
=?ISO-8859-1?Q?Jens_Oehlschl=E4gel?=