[Top][All Lists]

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

Re: Release plans

From: Thomas Lord
Subject: Re: Release plans
Date: Fri, 29 Aug 2008 15:53:50 -0700
User-agent: Thunderbird (X11/20060808)

Thien-Thi Nguyen wrote:
() Thomas Lord <address@hidden>
() Fri, 29 Aug 2008 12:23:20 -0700

   it would be very nice, performance-wise and semantics-wise, to
   be able to address the database from lisp directly rather than
   going through the serialization bottleneck to a sub-process.

I think you've got it backwards;

Actually I don't but there is a linguistic problem between
you and I (a minor one).

You contrast my advocacy for a dynamic loader with what
you propose as an alternative.   I'll just quote in full here since
it's short:

in any system involving Emacs (of
the current design), the serialization bottleneck is Emacs `eval'.
In this light, a subprocess is actually the most clean and (more
importantly) upwardly compatible way to scale performance.

If we wish to augment this extremely clean model:

  (1a) emacs
  (1b) emacs------------emacs           ; fork
  (1c) emacs--[serial]--subproc         ; exec

for performance purposes, then i suggest we concentrate on the
data structure for sharing info between emacs and the subproc,
rather than the control structure (i.e., dynamic loader).  More
precisely, i would like to see something like:

  (2a) emacs
  (2b) emacs--[sharable-buffer]         ; "sweep-porch"
  (2c) emacs---[shared-buffer]---emacs  ; "invite-kibitz" :-D

The second emacs (from 2c) can mux traditional children (1b, 1c)
as it sees fit, of course.

One little catch, please.   If you are going to have (2c) then
you also implicitly have:

     (2c') emacs -- [shared buffer] -- any[*]

     [*] any program that knows the buffer data structure
     and sharing protocol

In other words, (2c) is one possible API for a dynamic loader in

I think a dynamic loading API based on shared buffers is a very
good idea, by the way.   That is probably a better way to do it than
just a cut-and-paste dlopen job from some other app.  A shared buffer
API is just as much an invitation to non-free add-ons as a dlopen
API, but the shared buffer API is probably (I'd agree with you, if
we're just kibbitzing) better for free software developers, better for
Emacs maintainers, etc.

In Unix, the data structure for sharing info is a shared buffer,
but the protocol for manipulating that buffer is very limited.
Lots of fun ensued, anyway.  Emacs deserves no less.

I think that there are leaks in that abstraction -- it's not quite as
minimal and contained as I think you suggest.

For example, buffer have buffer local variables and have lexical
environments that include global scope so, ideally, the entire Emacs
lisp address space is accessible from a shared buffer.   The actual
API has to achieve that API or compromise with some simplifications.
I would expect a compromise, for practical reasons.   It is an
interesting medium-sized research project to search for a sweet-spot
API for shared buffers.  By what metric should we be invited to measure
the compromise?  and then how is the compromise implemented?  and
how does it perform? and what is it good for?



reply via email to

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