From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: What's the problem? (Was: Are there plans for a multi-threaded Emacs?) Date: Mon, 08 Dec 2003 14:56:32 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4nu14b6q33.fsf@collins.bwh.harvard.edu> 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 1070913585 22325 80.91.224.253 (8 Dec 2003 19:59:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Dec 2003 19:59:45 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 08 20:59:42 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 1ATRXh-00048N-00 for ; Mon, 08 Dec 2003 20:59: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 1ATRXh-0007uL-00 for ; Mon, 08 Dec 2003 20:59: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 1ATSTs-0002HX-4a for emacs-devel@quimby.gnus.org; Mon, 08 Dec 2003 15:59:48 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ATSTU-0002Gp-Ul for emacs-devel@gnu.org; Mon, 08 Dec 2003 15:59:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ATSSx-0001xB-ST for emacs-devel@gnu.org; Mon, 08 Dec 2003 15:59:23 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ATSSv-0001ps-Ej for emacs-devel@gnu.org; Mon, 08 Dec 2003 15:58:49 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATRVS-0006Hu-00 for ; Mon, 08 Dec 2003 20:57:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ATRVQ-0006Hl-00 for ; Mon, 08 Dec 2003 20:57:20 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ATRVQ-0005jb-00 for ; Mon, 08 Dec 2003 20:57:20 +0100 Original-Lines: 51 Original-X-Complaints-To: usenet@sea.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:aqkbIJ2qjSuwkzNlbgoC4ay7ca8= 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:18565 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18565 On 08 Dec 2003, luke@bluetail.com wrote: > What's the biggest problem that threads are intended to solve? (I'm talking about my own comments in this thread, and I'll try to summarize things) The interactive user experience, when tasks can be parallelized or backgrounded, could be *improved.* This is not a problem to be solved, it's an incremental improvement from the user's viewpoint. > Is it that it's too hard or ugly to write concurrent programs in > Elisp today? If so, what are some examples of bad cases that cause > users pain and _really_ can't be rewritten neatly and with happy > concurrency properties in plain old Elisp after some rethinking? 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. - auto-save on a slow file system or through Tramp - Gnus mail retrieval, summary thread building, registry lookups - independent hashtable lookups and calculations in parallel would be a very nice improvement in themselves, and I'm sure there are many applications that can use them > 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. I'm OK with any solution as long as it improves the user experience, and I'll work with whatever API is best. I would like that API to exist, though, and that doesn't seem to be the case with concurrency in Emacs today. Am I wrong? 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. 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. Ted