[Rd] R-devel Digest, Vol 83, Issue 2

[Laurent Gautier]

On 1/2/10 8:28 PM, Simon Urbanek wrote:
>
> On Jan 2, 2010, at 12:17 PM, Laurent Gautier wrote:
>
>> On 1/2/10 5:56 PM, Duncan Murdoch wrote:
>>> On 02/01/2010 11:36 AM, Laurent Gautier wrote:
>>>> [Disclaimer: what is below reflects my understanding from
>>>> reading the R source, others will correct where deemed
>>>> necessary]
>>>>
>>>> On 1/2/10 12:00 PM, r-devel-request at r-project.org wrote:
>>
(...)

>>> Another possibility is to maintain your own list or environment
>>> of objects, and just protect/preserve the list as a whole.
>>
>> Interesting idea, this would let one perform his/her own
>> bookkeeping on the list/environment. How is R garbage collection
>> checking contained objects ? (I am thinking performances here, and
>> may be cyclic references).
>>
>
> You don't really want to care because the GC is global for all
> objects (and cycles are supported by the GC in R) - so whether you
> keep it yourself or Preserve/Release is practically irrelevant (the
> protection stack is handled separately).

I guess that I'll have to know in order to understand that I don't 
really want to care. ;-)
The garbage collector must somehow know if an object is available for 
collection (and will have to check whether an object is PROTECTed or 
not, or Preserved or not).
I suppose that upon being called the garbage collector will first look 
into the PROTECTed and Preserved objects, mark them as unavailble for 
collection, then recursively mark objects contained in them.

> As for keeping your own list -- if you really care about performance
> that much (to be honest in vast majority of cases it doesn't matter)
> you have to be careful how you implement it. Technically the fastest
> way is preallocated generic vector but it really depends on how you
> deal with the access so you can easily perform worse than
> Preserve/Release if you're not careful.

Releasing being of linear complexity, having few thousands of Preserved 
objects not being anticipated as an extraordinary situation, and 
Preserve/Release cycles being quite frequent, I start minding a bit 
about the performance. Keeping my own list would let me experiment with 
various strategies (and eventually offer

> As a side note - the best way (IMHO) to deal with all those issues is
> to use external pointers because a) you get very efficient C
> finalizers b) you can directly (and very efficiently) tie lifespan of
> other objects to the same SEXP and c) as guardians they can nicely
> track other objects that hold them.

Thanks. I am not certain to follow everything. Are you suggesting that 
rather than Preserve-ing/Release-ing a list/environment that would act 
as a guardian for several objects, one should use an external pointer 
(to an arbitrary C pointer) ? In that case, how does one indicate that 
an external pointer acts as a container ?

Or are you suggesting that rather than Preserve-in/Release-ing R objects 
one should use an external pointer acting as a proxy for a SEXP 
(argument "prot" in R_MakeExternalPtr(void *p, SEXP tag, SEXP prot) ) ?
(but in that case the external pointer will itself have to go through 
Preserve/Release cycles...)


Cheers,


Laurent

> Cheers, Simon
>
>
>
>>
>>
>> L.
>>
>>
>>> Duncan Murdoch
>>>
>>>>
>>>>
>>>> HTH,
>>>>
>>>>
>>>> L.
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>> Romain
>>>>>
>>>>> [1]http://lists.r-forge.r-project.org/pipermail/rcpp-devel/
>>>>> [2]
>>>>> http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255&root=rcpp&view=markup
>>>>>
>>>>>
>>>>>
>>>>>
-- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30
>>>>> http://romainfrancois.blog.free.fr |- http://tr.im/IW9B : C++
>>>>> exceptions at the R level |- http://tr.im/IlMh : CPP package:
>>>>> exposing C++ objects `- http://tr.im/HlX9 : new package :
>>>>> bibtex
>>>>
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>