emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finding objects on C stack - alternate GCPRO


From: Eli Zaretskii
Subject: Re: Finding objects on C stack - alternate GCPRO
Date: Thu, 17 Nov 2011 18:50:33 +0200

> From: Stephen Berman <address@hidden>
> Date: Thu, 17 Nov 2011 13:50:11 +0100
> 
>       It suffices to ensure that at least one pointer to each object is
>    GC-protected; that way, the object cannot be recycled, so all pointers
>    to it remain valid.  Thus, a particular local variable can do without
>    protection if it is certain that the object it points to will be
>    preserved by some other pointer (such as another local variable which
>    has a `GCPRO')(1).  Otherwise, the local variable needs a `GCPRO'.
> 
> If this is only needed on platforms that don't support gcc, shouldn't
> the manual say that, or should GCPRO be mentioned at all?

As long as Emacs supports platforms that don't use conservative stack
marking, we cannot drop GCPROs from the sources, and we cannot stop
requesting that new code uses GCPROs where they are needed on those
few platforms.

Btw, it's not GCC that allows to make GCPRO a no-op, it's the fact
that the platform supports stack marking.  I only mentioned GCC
because the proposed alternative method does require GCC.

> Perhaps I'm completely missing the point, since the only thing I
> know about GCPRO is what's in the manual; if so, could someone
> elaborate on the role of GCPRO, or if that's inappropriate here,
> point me to relevant places (preferable comments) in the Emacs
> sources or relevant external discussion?  Thanks.

GCPRO is needed when the C sources have pointers extracted from Lisp
objects and want to preserve them across calls to `eval'.  E.g., if
you hold the pointer to the data of a Lisp_String in a C variable, and
then call a function that can directly or indirectly call `eval'.  In
such cases, you want to tell GC that the Lisp object cannot be GC'ed.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]