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

From: Laurent Gautier <lgautier_at_gmail.com>
Date: Sat, 02 Jan 2010 22:08:26 +0100

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



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat 02 Jan 2010 - 21:11:35 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sun 03 Jan 2010 - 01:00:10 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive