From simon.urbanek at r-project.org  Mon Mar  3 21:50:37 2014
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Mon, 3 Mar 2014 15:50:37 -0500
Subject: [Rd] internal copying in R (soon to be released R-3.1.0
In-Reply-To: <5314E78F.4030804@truecluster.com>
References: <53136C77.2010603@truecluster.com>
	<E4137A27-9188-4932-891E-7451ACEDC7C2@r-project.org>
	<5314E78F.4030804@truecluster.com>
Message-ID: <F6070CCD-9C5B-4682-BE85-0F8DAD5F1C49@r-project.org>

Jens,

On Mar 3, 2014, at 3:35 PM, Jens Oehlschl?gel <jens.oehlschlaegel at truecluster.com> wrote:

> 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.
> 

If NAMED > 0 then calling duplicate() is necessary to make sure you have a non-shared copy.


> > 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."

Matthew pointed out that line and I cannot shed more light on it, since it's not true - at least not currently.


> This is consistent with the observation of my test code: that NAMED() in .Call always returns 2.

It is not - you're not testing .Call() - your'e testing the assignments in frames which cause additional bumps of NAMED. If you actually test .Call() you'll see what I have reported - .Call() itself does NOT affect NAMED.


> 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.
> 

Again, as I said earlier, you're on the wrong track here - .Call() doesn't touch it - it is left to the C code. Note that NAMED cannot be decremented (unless you use a ref counting version of R) once it reaches 2 since that means "two or more" so. The only time where you can decrement it is if you are the owner that set it from 0 to 1.

Cheers,
Simon


> 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
Simon Urbanek