|
From: | Dmitry Antipov |
Subject: | Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. |
Date: | Wed, 08 Aug 2012 11:14:12 +0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 |
On 08/08/2012 07:39 AM, Chong Yidong wrote:
Another problem, which I haven't seen mentioned in this thread, is that when you see C code which does FVAR (x, y) the natural assumption is that x and y are C variables. So these macros hurt code readability. The introduction of BVAR also violated this principle, and I'm not eager to see the problem compounded.
It looks like we should think about how to redesign BVARs and KVARs so that it should be suitable both for GC and concurrency development.
I think FSET/WSET/PSET/PGET/etc should be removed from the trunk, at least for now. I recommend moving the generational GC work to a branch.
Look at the size of changes I did just for a few days. This is just a preliminary changes needed to implement write barriers on top of them. Each pointer store is a subject to handle; most probably each source file will be affected. I suppose that new GC tree will look so different so the final merge will be a tremendous task on a few weeks. So I'm thinking about 2-stage approach: preliminary work is in trunk (where it might be used for concurrency branch and other development), and new GC (barriers and core GC bits) is in branch. Dmitry
[Prev in Thread] | Current Thread | [Next in Thread] |