[Top][All Lists]

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

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIEL

From: Dmitry Antipov
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Thu, 02 Aug 2012 11:47:05 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 08/02/2012 09:56 AM, Stephen J. Turnbull wrote:

  > Look at concurrency branch. Everyone agrees that this is an
  > interesting and useful feature,

I don't think that's true.  Emacs needs concurrency, it's true.  It's
not obvious that Emacs Lisp does.

Hm, I mean not only Lisp-level threads, but also implicit concurrency
like one thread per frame or similar things.

  > but no one wants to handle an endless merging efforts.  If we had
  > the same amount of developers as involved in Linux kernel,

It's not the number of developers, it's the customary discipline in
the community.  SXEmacs has a far smaller number of developers than
GNU Emacs does, but they branch like crazy and seem to love it.  Many
projects do.

I agree, but only when the feature is more or less isolated (like
BIDI, IIUC). Most probably new GC will introduce new limitations on
how the Lisp_Objects may be used, and, unfortunately, these limitations
should be enforced through the whole project _before_ new GC becomes
alive for the first time. For the particular write barriers case, just
one bypass is most likely to crash everything; so, barriers should be
designed and implemented first, and all developers should be encouraged
to remember about them and obey new limitations when writing new code
or fixing an old bugs. The only reliable way to do it is to have barriers
in the trunk (defined to zero-overhead no-ops in the default configuration,
of course).

Merging really isn't that bad if your architecture is designed for it
and your workflow adapted to it.

This is not the matter or _my_ architecture; current code base provides
very poor opportunities for any GC designer, and this should be changed
_before_ any useful GC improvements may be implemented. Everyone wants
a new house, but nobody wants to suffer the temporary inconveniences
connected with building; but (if the house is large enough) it's
practically impossible to build the house somewhere else and then
transport it to the final destination.


reply via email to

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