From osklyar at ahl.com  Wed Apr 14 10:21:38 2010
From: osklyar at ahl.com (Sklyar, Oleg (London))
Date: Wed, 14 Apr 2010 09:21:38 +0100
Subject: [Rd] Why no race condition when returning UNPROTECT-ed memory
 fromC?
In-Reply-To: <j2wd4cf43b61004132250s14a6ee9cmc89be3266eb3e721@mail.gmail.com>
References: <j2wd4cf43b61004132250s14a6ee9cmc89be3266eb3e721@mail.gmail.com>
Message-ID: <1A68FCB28DE72F4BA3B967E6506CCE430662AFA7@mildnpexmb01.maninvestments.ad.man.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}}



[Rd] Why no race condition when returning UNPROTECT-ed memory fromC?
Sklyar, Oleg (London