From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 04 Dec 2003 10:37:35 -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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070552708 1211 80.91.224.253 (4 Dec 2003 15:45:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 15:45:08 +0000 (UTC) Cc: bob@rattlesnake.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 16:45:03 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 1ARvf5-000867-00 for ; Thu, 04 Dec 2003 16:45:03 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARvf5-00015o-00 for ; Thu, 04 Dec 2003 16:45:03 +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 1ARwXh-0004Kr-D0 for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 11:41:29 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARwWk-000473-0R for emacs-devel@gnu.org; Thu, 04 Dec 2003 11:40:30 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARwWC-0003vX-Vs for emacs-devel@gnu.org; Thu, 04 Dec 2003 11:40:28 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARwVa-0003hi-M6; Thu, 04 Dec 2003 11:39:18 -0500 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (8.12.9/8.12.9) with ESMTP id hB4Fbabj013445; Thu, 4 Dec 2003 10:37:36 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id DC4C83CFD9; Thu, 4 Dec 2003 10:37:35 -0500 (EST) Original-To: rms@gnu.org In-Reply-To: Original-Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner: Found to be clean 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:18371 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18371 > A lock on with-current-buffer can't really solve the problem, > because only a few of the functions that modify a buffer > use with-current-buffer. I don't think we can have a fool-proof solution short of using separate processes with explicit communication. So my proposal is just to allow wildly dangerous multi-threading and provide a few synchronising constructs such that if people really want to, they can write multithreaded code, although at a cost of extreme care. > However, perhaps you're thinking of allowing a few specially-designated > asynchronous threads, each of which would edit only its own buffer or buffers > so that they won't get in each others' way, that might work if the code > that runs in these specially-designated threads is specially written to > be safe in such a thread. 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. > MIGHT be workable. The devil is in the details, so someone would Yes, my proposition only addresses the issue from a "threading model for the elisp programmer" point of view. Given the extensive internal use of global variables in the C code, a significant amount of code-review would be needed to get rid of problems such as the regexp.c code being non-reentrant, unless we do the preemption manually in Feval and even then, we'll probably encounter unexpected problems. Stefan