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: What's the problem? (Was: Are there plans for a multi-threaded Emacs?) Date: 08 Dec 2003 21:56:56 +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> <4nu14b6q33.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 1070917366 31111 80.91.224.253 (8 Dec 2003 21:02:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2003 21:02:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 08 22:02:41 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 1ATSWf-0000bE-00 for ; Mon, 08 Dec 2003 22:02:41 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATSWf-0000Uk-00 for ; Mon, 08 Dec 2003 22:02:41 +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 1ATTT4-0005FK-Eb for emacs-devel@quimby.gnus.org; Mon, 08 Dec 2003 17:03:02 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATTPH-0004Dq-5g for emacs-devel@gnu.org; Mon, 08 Dec 2003 16:59:07 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATTOf-00044q-Ul for emacs-devel@gnu.org; Mon, 08 Dec 2003 16:59:00 -0500 Original-Received: from [62.226.11.245] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ATTOc-00043t-TI for emacs-devel@gnu.org; Mon, 08 Dec 2003 16:58:27 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB8Kuwus001377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2003 21:56:58 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB8Kuvrn001373; Mon, 8 Dec 2003 21:56:57 +0100 Original-To: Ted Zlatanov In-Reply-To: <4nu14b6q33.fsf@collins.bwh.harvard.edu> Original-Lines: 82 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:18567 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18567 Ted Zlatanov writes: > On 08 Dec 2003, luke@bluetail.com wrote: > > > What's the biggest problem that threads are intended to solve? > > Note I don't claim these can't be rewritten in a concurrent fashion. > I simply gave examples that could stand to be improved. The > majority of examples are in Gnus, because that's the Elisp > application I know best. Have you already done the obvious thing of setting gnus-asynchronous to a non-nil value? That's the least one would expect from somebody that wants parallelism that badly. > - auto-save on a slow file system or through Tramp So that if autosave starts saving a file and is half through when I decide that the first half of the file is junk I won't need and delete it, Emacs finds itself having saved more than enough material and stops writing, never saving the remaining _important_ part of the file? You can't just throw in parallelism and hope that things will work out somehow. > - Gnus mail retrieval, summary thread building, registry lookups Most of those can be controlled with gnus-asynchronous and subordinate variables. > - independent hashtable lookups and calculations in parallel would > be a very nice improvement in themselves, Why? What time-critical code performs them frequently? > > People are writing concurrent programs in Elisp today. Most > > programs interacting with external processes and sockets do so > > without blocking Emacs. Can't we all just do the same? > > There seems to be interest in a real multithreading solution, be it > cooperative or preemptive, or an event-driven API. The interest I have heard voiced so far has not been overly correlated with intimate technical knowledge about the details involved and the actual differences this would make for everyday work. > If it appears from this thread that I have a particular interest in > a radical rewrite of Emacs, that is not true. It just seems to me, > because of the tight internal coupling of Emacs functions and > variables, that lightweight threads would be a good choice for the > internal implementation of the API because they have less baggage > than process sentinels and share data more easily. And sharing data more easily is exactly what one can't afford in a language with dynamic binding, since you get no closures whatsoever. If I have something like (let ((x (+ y 2))) do something) then I can't afford to have some other thread change the meaning of x in his own (let ((x ... construct. If you want to afford a separate binding stack for every thread, this also means that every _read_ _access_ to a symbol must run via the thread's binding stack instead of just using the stack whenever the a binding _changes_. And it is not only local variables that get temporarily bound: there are common constructs like (let ((process-connection-type nil)) [...]) where global variables get some value for some short duration. > I also mentioned that today's hardware and OS support for it > generally means that either multiple processors or the illusion of > them is available to applications that are willing to make use of > those capabilities. Applications don't have a will of their own, even though it sometimes may appear so. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum