Re: Release plans

[Thomas Lord <lord@emf.net>]

Thien-Thi Nguyen wrote:
> () Thomas Lord <lord@emf.net>
> () 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
Emacs.

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?

-t





> thi
>
>
>
>