emacs-devel
[Top][All Lists]
Advanced

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

Buffer-/frame-local variables [Was: Re: Make buffer- and frame-locals a


From: Dmitry Antipov
Subject: Buffer-/frame-local variables [Was: Re: Make buffer- and frame-locals a misc object]
Date: Thu, 16 Aug 2012 08:10:53 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 08/15/2012 08:02 PM, Stefan Monnier wrote:

For 1), my previous (and inglorious) attempt to hack around
save-excursion shows that mixing explicitly allocated/freed objects
with GC-managed objects is poor idea, so getting rid of xmalloc/xfree
makes the things more predictable.

Fear of the unknown is not a good motivation for a change ;-)
Have you found out what was the problem?

The problem was that the marker embedded into struct Lisp_Excursion
can be linked to buffer's undo list; when struct Lisp_Excursion gets
xfree'd, the marker pointer from undo list becomes dangling.

But in any case the current use of xmalloc/xfree for Lisp_Buffer_Local_Value
doesn't show any sign of suffering from a similar problem.

OK

For 2), the usual purpose is to prepare the hooks for the write barrier.

Why have get_blv_value, since it's not needed for a write barrier?
The set_blv_* are OK, OTOH.

OK. So please consider attached patch for the trunk.

I do wonder, tho: do we need those write-barriers in the object-creation
function (e.g. make_buffer_local_value)?

In general, no, since all just allocated objects are new by definition,
and write barrier action is raised only if the pointer to new object is
stored into an old one. So, the write barrier is installed but never
raised; I remember about this, and, of course, such a cases will be
optimized away.

Dmitry

Attachment: blv.patch
Description: Text document


reply via email to

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