From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 04 Dec 2003 13:06:55 -0500 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> <87ptf5zn4k.fsf@kanga.tapsellferrier.co.uk> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1070561704 23044 80.91.224.253 (4 Dec 2003 18:15:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 18:15:04 +0000 (UTC) Cc: bob@rattlesnake.com, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 19:15:01 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 1ARy0D-0003pF-00 for ; Thu, 04 Dec 2003 19:15:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARy0C-0002vD-00 for ; Thu, 04 Dec 2003 19:15:01 +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 1ARyvU-0006ae-Sg for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 14:14:12 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARyuq-0006X8-Iw for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:13:32 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARyrd-0004zM-0V for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:10:44 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ARyqy-0004Pe-J9; Thu, 04 Dec 2003 14:09:32 -0500 Original-Received: from [207.245.84.69] (helo=colo.agora-net.com) by mx20.gnu.org with esmtp (Exim 4.24) id 1ARxsP-00057C-GG; Thu, 04 Dec 2003 13:06:57 -0500 Original-Received: from ttn by colo.agora-net.com with local (Exim 3.34 #1) id 1ARxsN-0007Vb-00; Thu, 04 Dec 2003 13:06:55 -0500 Original-To: Stefan Monnier In-Reply-To: Stefan Monnier's message of "04 Dec 2003 10:37:35 -0500" Original-Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.7 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:18390 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18390 Stefan Monnier writes: Yes, that's the idea. I was thinking in terms of "what's the minimal amount of parallelism needed to get similar benefits as current async-I/O (via process-filters) but for CPU-bound tasks, such as Gnus's construction of the summary buffer". I think in all the important cases, the CPU-bound tasks runs in a single buffer and that buffer is not modified/used by other code, so locking at that level makes sense. this is a nice idea, the "locked-loopback-buffer" abstraction. locking requires declaration of all variables needed to be passed in, unlocking passes out new values (if any) plus the modified buffer text. you can even avoid threads entirely. for implementation, fork an inferior emacs and use the already-in-place async-I/O facilities. two afternoons and a nap! who needs multi-threadache anyway? thi