R devel - Apr 2010 - Why no race condition when returning UNPROTECT-ed memory from C?

Consider the C (or C++) code called from the .Call interface:
SEXP foo() {
  SEXP *p = PROTECT(allocVector(REALSXP, 10));
  ...
  UNPROTECT(1);
  return p;
}

Why is there no danger that the allocated memory will be garbage
collected after the UNPROTECT, but before the return of p?

I have used code like this for some time and have never had a
problem, but I'm not sure if/why it is guaranteed to work.

Thanks,
Dominick

	[[alternative HTML version deleted]]

On Apr 14, 2010, at 7:50 AM, Dominick Samperi wrote:
> Consider the C (or C++) code called from the .Call interface:
> SEXP foo() {
>  SEXP *p = PROTECT(allocVector(REALSXP, 10));
>  ...
>  UNPROTECT(1);
>  return p;
> }
> 
> Why is there no danger that the allocated memory will be garbage
> collected after the UNPROTECT, but before the return of p?
> 
> I have used code like this for some time and have never had a
> problem, but I'm not sure if/why it is guaranteed to work.
Garbage collection is only triggered by allocation. The hard bit is to remember
exactly which programming constructs might allocate something, but in the above,
there aren't any. You need to watch out with the unprotected return value,
though: fee(foo(), fum()) is a standard bug source if fum() allocates.


-- 
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com

Because there is no second thread to do that, R is single threaded. The
gc could only be run from within another R API command or macro, but
there is none in between.

Best
Oleg

Dr Oleg Sklyar
Research Technologist
AHL / Man Investments Ltd
+44 (0)20 7144 3803
osklyar at maninvestments.com 
> -----Original Message-----
> From: r-devel-bounces at r-project.org 
> [mailto:r-devel-bounces at r-project.org] On Behalf Of Dominick Samperi
> Sent: 14 April 2010 06:51
> To: r-devel at r-project.org
> Subject: [Rd] Why no race condition when returning 
> UNPROTECT-ed memory fromC?
> 
> Consider the C (or C++) code called from the .Call interface:
> SEXP foo() {
>   SEXP *p = PROTECT(allocVector(REALSXP, 10));
>   ...
>   UNPROTECT(1);
>   return p;
> }
> 
> Why is there no danger that the allocated memory will be garbage
> collected after the UNPROTECT, but before the return of p?
> 
> I have used code like this for some time and have never had a
> problem, but I'm not sure if/why it is guaranteed to work.
> 
> Thanks,
> Dominick
> 
> 	[[alternative HTML version deleted]]
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
**********************************************************************
 Please consider the environment before printing this email or its attachments.
The contents of this email are for the named addressees ...{{dropped:19}}