Re: [Rd] Why no race condition when returning UNPROTECT-ed memory from C?
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@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why no race condition when returning UNPROTECT-ed memory fromC?
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
oskl...@maninvestments.com
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Dominick Samperi
> Sent: 14 April 2010 06:51
> To: r-devel@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@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}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN: MacOS X binary: not available, see check log?
For a couple of days, MacOS X binaries are not build on CRAN (for my recently uploaded packages only?): The R.oo package is listed as "MacOS X binary: not available, see check log?", but the 'check log' show no errors URL: http://cran.r-project.org/web/packages/R.oo/ Is this a known issue? /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
