unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: emacs-devel@gnu.org
Subject: Re: Finding objects on C stack - alternate GCPRO
Date: Thu, 17 Nov 2011 18:50:33 +0200	[thread overview]
Message-ID: <83ipmid76u.fsf@gnu.org> (raw)
In-Reply-To: <87ehx6q5fg.fsf@escher.home>

> From: Stephen Berman <stephen.berman@gmx.net>
> 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	other threads:[~2011-11-17 16:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16 10:07 Finding objects on C stack - alternate GCPRO Dmitry Antipov
2011-11-16 10:18 ` Helmut Eller
2011-11-16 10:33   ` Dmitry Antipov
2011-11-16 23:27   ` Richard Stallman
2011-11-17  4:17     ` Stephen J. Turnbull
2011-11-17 19:12       ` Richard Stallman
2011-11-16 11:06 ` Eli Zaretskii
2011-11-17 12:50   ` Stephen Berman
2011-11-17 16:50     ` Eli Zaretskii [this message]
2011-11-16 14:41 ` Stefan Monnier
2011-11-16 18:19 ` Tom Tromey
2011-11-16 21:07 ` Ken Raeburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ipmid76u.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=stephen.berman@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).