On 8/24/2009 9:33 AM, Saptarshi Guha wrote:
Thank you. So the reason I wouldnt need to protect y had I returned to
R, is because
had i had done something like
h<-.Call("boo",a)
where "boo" contains y=foo()
the assignment "<-" to h would have a PROTECT somewhere, i.e R's
assignment is doing the protection for me.
Once the object is assigned to h, then it is stored in the global
environment, so it is safe from garbage collection without needing to be
PROTECTed. It's just in the short time after creation before storage
where it's at risk.
One general rule in R is that things are in use if they are part of
something that is in use (and the global environment is always in use).
PROTECT is another way to mark something as being in use. When
something is in use the garbage collector will leave it alone.
Duncan Murdoch
Had I not returned to R, I would have to do it myself.
Yes PROTECT is quite cheap, I had thought it to be costly but 1MM
PROTECT/UNPROTECT calls, takes <1 second (on a macbook 2.16ghz)
Thanks for the explanation.
Regards
Saptarshi
On Mon, Aug 24, 2009 at 9:24 AM, Duncan Murdoch<murd...@stats.uwo.ca> wrote:
On 8/24/2009 9:10 AM, Sapsi wrote:
Hello
Thank you for the response. So if my call is
y=foo()
z=malloc ( by memory allocations , do you mean via R_alloc and
allocVector and malloc or just the former two)
Any allocation which is managed by R's memory manager, so that includes the
former two, and many other kinds of calls which do allocations, i.e.
essentially any call to the R API unless it's documented not to do
allocations. In most cases calling PROTECT is quite cheap, so it is worth
doing if you're not sure. (There are exceptions: because the PROTECT stack
is finite, you can overflow it if you PROTECT too much. That could happen in
a loop or a deep recursion.)
Other statements
Then I need to protect y. And in my case I don't return to R since I
have embedded it.
Why is this the case I.e if I perform mem allocs , I need to protect y
Because R's memory manager does automatic garbage collection. If you don't
protect y, then the memory manager will not know that it is still in use.
The next time it needs some memory it may decide to free y and re-use that
space.
Duncan Murdoch
On Aug 24, 2009, at 8:18 AM, Duncan Murdoch <murd...@stats.uwo.ca>
wrote:r
C
On 8/23/2009 11:52 PM, Saptarshi Guha wrote:
Hello,
Suppose I have the function
SEXP foo(){
SEXP s;
PROTECT(s=allocVector(...))
....
UNPROTECT(1);
return(s)
}
y=foo() // foo is a recusrive call
Q: Am i correct in understanding that one does not need to write
PROTECT(y=foo()) ?(and a corresponding unprotect later on)
since it is the object that is protected , SEXP is an alias for
SEXPREC* and allocVector probably does some memory allocation which
does not get freed
when foo returns.
Whether y needs protecting depends on what happens between the y = foo()
call and the time you return to R. If nothing happens, i.e. you just
return y to R, then you're safe. If you do any memory allocations after
that call before returning to R then y will need to be protected.
Duncan Murdoch
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
