[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Buffer-/frame-local variables [Was: Re: Make buffer- and frame-local
Re: Buffer-/frame-local variables [Was: Re: Make buffer- and frame-locals a misc object]
Fri, 17 Aug 2012 09:20:14 -0400
Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)
>>> 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.
So, the problem is not that the Lisp_Excursion used malloc/free, but
that the marker used malloc/free (implicitly by being embedded in the
Lisp_Excursion) although it can get captured by other pointers.
> OK. So please consider attached patch for the trunk.
See comments below.
>> 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
Another reason is that until they're initialized, the fields contain
invalid values, so if the GC sees them we're in trouble, right?
- valcontents = BLV_VALUE (blv);
+ valcontents = XCDR (blv->valcell);
Please don't: BLV_VALUE is more clear and abstract (same applies to
other places where you replace BLV_VALUE with XCDR (blv->valcell)).
-#define BLV_FOUND(blv) \
+get_blv_found (struct Lisp_Buffer_Local_Value *blv)
Why add a "get_" prefix?
Elisp and Emacs generally uses "<type>-<field>" for accessors and
"set-<type>-<field>" for setters.