From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: Release plans Date: Fri, 29 Aug 2008 15:53:50 -0700 Message-ID: <48B87DFE.80806@emf.net> References: <20080818101802.GA2615@muc.de> <87bpzqqk7b.fsf@uwakimon.sk.tsukuba.ac.jp> <20080818210927.GD2615@muc.de> <87wsidnxqp.fsf@uwakimon.sk.tsukuba.ac.jp> <87ljytkwpk.fsf@rattlesnake.com> <878wusz0v9.fsf@uwakimon.sk.tsukuba.ac.jp> <87vdxp27z6.fsf@uwakimon.sk.tsukuba.ac.jp> <87prnxe5hc.fsf@rattlesnake.com> <873aktck5d.fsf@uwakimon.sk.tsukuba.ac.jp> <87k5e5dsvq.fsf@rattlesnake.com> <48B44802.1080302@emf.net> <87ej4atczj.fsf@gmail.com> <48B78A75.8080103@emf.net> <803akoyrqy.fsf@tiny.isode.net> <48B7F59B.5060705@gmail.com> <48B84CA8.7080908@emf.net> <87zlmvd1xl.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1220047388 11177 80.91.229.12 (29 Aug 2008 22:03:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Aug 2008 22:03:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 30 00:04:02 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KZC4T-0003lP-Dp for ged-emacs-devel@m.gmane.org; Sat, 30 Aug 2008 00:03:57 +0200 Original-Received: from localhost ([127.0.0.1]:59888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZC3U-0008LQ-Ih for ged-emacs-devel@m.gmane.org; Fri, 29 Aug 2008 18:02:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZC3P-0008K4-Dc for emacs-devel@gnu.org; Fri, 29 Aug 2008 18:02:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZC3O-0008JG-T0 for emacs-devel@gnu.org; Fri, 29 Aug 2008 18:02:51 -0400 Original-Received: from [199.232.76.173] (port=60424 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZC3O-0008JD-Qz for emacs-devel@gnu.org; Fri, 29 Aug 2008 18:02:50 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:55605) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KZC3O-0007PZ-9C for emacs-devel@gnu.org; Fri, 29 Aug 2008 18:02:50 -0400 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.75.128] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 37931069; Fri, 29 Aug 2008 15:02:46 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <87zlmvd1xl.fsf@ambire.localdomain> X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:103218 Archived-At: Thien-Thi Nguyen wrote: > () Thomas Lord > () 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 > > > >