On Apr 19, 2010, at 10:39 AM, Melissa Jane Hubisz wrote: > Hello, > The Writing R extensions manual section 6.1.1 describes the transient > memory allocation function R_alloc, and states that memory allocated > by R_alloc is automatically freed after the .C or .Call function is > completed. However, based on my understanding of R's memory handling, > as well as some test functions I have written, I suspect that this is > not quite accurate. If the .Call function returns an external pointer > to something created with R_alloc, then this object seems to stick > around after the .Call function is completed, and is subject to > garbage collection once the external pointer object is removed. >
Yes, because the regular rules for the lifetime of an R object apply since it is in fact an R object. It is subject to garbage collection so if you assign it anywhere its lifetime will be tied to that object (in your example EXTPTRSXP). Although this is true in general (because that is the only way how it can be safely managed by the memory system), I'm not sure it is guaranteed by the API - i.e. it could be changed at any point to an arbitrary memory location which does not necessarily have that semantics. So you can decide to run with it but the fact that this is undocumented means it is not guaranteed to stay that way forever so you may need to change your code if it does. Cheers, Simon > Does anyone know, can I count on this behavior on any platform? It > would certainly be useful for me. ie, Can I create an external > pointer to something created with R_alloc, and trust that it will not > be free'd until the external pointer object is removed? And if so, > should the manual be edited to describe this behavior? > Thanks, > Melissa Hubisz > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
