emacs-devel
[Top][All Lists]
Advanced

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

Re: Release plans


From: Thien-Thi Nguyen
Subject: Re: Release plans
Date: Fri, 29 Aug 2008 22:03:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

() 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; 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.

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.

thi




reply via email to

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