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: Sat, 30 Aug 2008 16:07:51 -0700 Message-ID: <48B9D2C7.4070103@emf.net> References: <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> <87myiub7tm.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 1220134632 26837 80.91.229.12 (30 Aug 2008 22:17:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Aug 2008 22:17:12 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 31 00:18:06 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 1KZYlg-00057W-TV for ged-emacs-devel@m.gmane.org; Sun, 31 Aug 2008 00:18:05 +0200 Original-Received: from localhost ([127.0.0.1]:46861 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZYkh-0002EP-8e for ged-emacs-devel@m.gmane.org; Sat, 30 Aug 2008 18:17:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KZYkd-0002E2-3q for emacs-devel@gnu.org; Sat, 30 Aug 2008 18:16:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KZYkb-0002DU-0Q for emacs-devel@gnu.org; Sat, 30 Aug 2008 18:16:58 -0400 Original-Received: from [199.232.76.173] (port=50900 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KZYka-0002DR-Qt for emacs-devel@gnu.org; Sat, 30 Aug 2008 18:16:56 -0400 Original-Received: from mail.42inc.com ([205.149.0.25]:56409) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KZYka-0003ck-BQ for emacs-devel@gnu.org; Sat, 30 Aug 2008 18:16:56 -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 37982985; Sat, 30 Aug 2008 15:16:42 -0700 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: <87myiub7tm.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:103278 Archived-At: Thien-Thi Nguyen wrote: > So no, i don't think the bottleneck would be the buffer access (for this > design), because the subprocess does not really need to access the buffer. > Changes to the buffer that have not yet hit the filesystem can be > communicated by publishing some portion of `buffer-undo-list' (which is > also relatively lightweight). > So, the sub-process basically contains a text editor in this design, albeit one without redisplay code and with an unusual, limited command set. That need for redundant code to make this thing work helps to prove that, indeed, the absence of dynamic loading (including just shared memory regions for buffers) creates make-work to work around it. I'm also skeptical about the performance claims here. A full update involves changing the buffer, print + system calls to inform the sub-process, system calls + read to get back the results of the parse updates, and then the actual text property updates. For interactive typing that can probably keep up on a modern machine but for other stuff it can easily be a performance bottleneck. (Still, even if it is not, it's doing it "the hard way".) > and it can be very costly to pass that text to the subprocess and > then process the returned value (which may look like a list of text > properties to add to various parts of the text). > > Well... > > A DLL could be significantly more efficient. The difference can be as > large as "on-the-fly" vs "batch". > > ...i suppose i'll have to agree that all these "could be" scenarios are > possible. My view is that given the requirement of external symbol tables > (and other state), the biggest win for both performance and maintainability > is to go asynchronous. If you want async from a subprocess, no worries, > but if you want async in-process, you need to either design (and debug and > maintain) "ethreads", or make Emacs play nice w/ pthreads or quickthreads > or phase-of-the-moon-threads or whathaveyou. Then, you need to make sure > every visitor treats your program counter w/ the respect it deserves. > That's a lot of thankless and brutish police work. > That seems exaggerated. A hook in the interact loop that locked a shared mem buffer briefly while asking for updates from an incremental parser / ide-helper doesn't seem like it would be all that hard to get right. -t