From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 08 Dec 2003 18:09:07 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <87oevbes4h.fsf@emacswiki.org> <20031117040607.C6C5D79B72@server2.messagingengine.com> <87ekvpx18d.fsf@emptyhost.emptydomain.de> <4nad6cikxy.fsf@holmes.bwh.harvard.edu> <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> <5bad69zd43.fsf@lister.roxen.com> <4noeuon378.fsf@lockgroove.bwh.harvard.edu> <4ny8tsgxy6.fsf@lockgroove.bwh.harvard.edu> <4nhe0ggv0u.fsf@lockgroove.bwh.harvard.edu> <4nk75bwjaf.fsf@lockgroove.bwh.harvard.edu> <4nsmjv8d32.fsf@collins.bwh.harvard.edu> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070903477 31918 80.91.224.253 (8 Dec 2003 17:11:17 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2003 17:11:17 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 08 18:11:14 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATOug-00008i-00 for ; Mon, 08 Dec 2003 18:11:14 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATOuf-00058E-00 for ; Mon, 08 Dec 2003 18:11:14 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATPqu-0006v3-Nj for emacs-devel@quimby.gnus.org; Mon, 08 Dec 2003 13:11:24 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATPqg-0006tS-Kr for emacs-devel@gnu.org; Mon, 08 Dec 2003 13:11:10 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATPqA-0006cW-GL for emacs-devel@gnu.org; Mon, 08 Dec 2003 13:11:09 -0500 Original-Received: from [62.226.11.173] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ATPq9-0006bw-4k for emacs-devel@gnu.org; Mon, 08 Dec 2003 13:10:37 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB8H98us000925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2003 18:09:09 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB8H98HW000921; Mon, 8 Dec 2003 18:09:08 +0100 Original-To: Ted Zlatanov In-Reply-To: <4nsmjv8d32.fsf@collins.bwh.harvard.edu> Original-Lines: 52 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:18556 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18556 Ted Zlatanov writes: > On 07 Dec 2003, monnier@iro.umontreal.ca wrote: > > > Now, that doesn't mean you can't do it, but just that it's going > > to be a lot of work and it might introduce subtle > > incompatibilities, so you need a lot of motivation to start the > > effort and you'll need really good arguments to convince RMS that > > breaking compatibility is worth the pay off. Now what is the > > payoff ? Speed. Given the fact that elisp is known to be slow, > > and that pretty much no work has been done to speed up Emacs in > > the last N years, I get the impression that nobody really cares > > about speed here. > > I have faith that the applications will come, once the core supports > them. Just think, for instance, of a mapcar that spreads out onto > as many processors as possible - doesn't that sound exciting? No. We are talking about an editor here, not a number crunching package. One fundamental difference is that a vast majority of Emacs Lisp constructs is _supposed_ to have side effects, in spite of being written in a functional language. > In addition, I should point out that speed in itself is not my > stated goal. Yes, maybe there will be some speed improvements, but > that's not what I've been asking for. Multithreading makes software > more responsive to the user, especially if the UI thread can be > separated from the other threads. Even if the software is actually > slower, it will serve the user better when it's more responsive, and > it will seem faster. I'm generalizing quite a bit, but have you > ever waited for a web browser to load all the images before > proceeding to use the web page? That's what using Emacs feels like > sometimes, as wonderful as it is. Emacs is not a browser, it is an editor. If I execute some keystrokes that will mark a region and then press the delete key before the operation that will mark the region actually has completed, I won't be happy if it instead deletes what happens to be at the time marked by something else. I don't want Emacs to start executing keystrokes before it has processed the previous keystrokes. I _want_ Emacs in general to process the things in the correct order when editing. > That being said, I realize that asking the Emacs developers to drop > other work to write multi-threading support is a tough call, and I'm > not the one to make it. I just hope the core developers get excited > enough about the possibilities that they will plan for some sort of > multithreading. See above comment from Stefan. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum