From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Martin Stjernholm Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: Fri, 05 Dec 2003 14:16:34 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5biskv2yml.fsf@lister.roxen.com> 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> <5bptf4ebw8.fsf@lister.roxen.com> <4nu14ggwvq.fsf@lockgroove.bwh.harvard.edu> <5bd6b4dw8t.fsf@lister.roxen.com> <4n1xrjxydt.fsf@lockgroove.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 1070630266 5855 80.91.224.253 (5 Dec 2003 13:17:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 5 Dec 2003 13:17:46 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Dec 05 14:17:43 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 1ASFq3-0001dE-00 for ; Fri, 05 Dec 2003 14:17:43 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ASFq2-0003Ec-00 for ; Fri, 05 Dec 2003 14:17:43 +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 1ASGnQ-0000QF-Nn for emacs-devel@quimby.gnus.org; Fri, 05 Dec 2003 09:19:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ASGn1-0000Q1-Qj for emacs-devel@gnu.org; Fri, 05 Dec 2003 09:18:39 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ASGmV-00009P-Lm for emacs-devel@gnu.org; Fri, 05 Dec 2003 09:18:38 -0500 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ASGmV-00009M-3q for emacs-devel@gnu.org; Fri, 05 Dec 2003 09:18:07 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 482DE9B23; Fri, 5 Dec 2003 14:16:40 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id AA16F9A38; Fri, 5 Dec 2003 14:16:34 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1ASFox-0008Nf-00; Fri, 05 Dec 2003 14:16:35 +0100 Original-To: Ted Zlatanov In-Reply-To: <4n1xrjxydt.fsf@lockgroove.bwh.harvard.edu> (Ted Zlatanov's message of "Fri, 05 Dec 2003 07:06:06 -0500") User-Agent: Gnus/5.090016 (Oort Gnus v0.16) Emacs/20.7 (gnu/linux) 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:18415 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18415 Ted Zlatanov wrote: > On Fri, 05 Dec 2003, mast@lysator.liu.se wrote: > >> Reading or writing are blocking operations, so they would be >> executed in parallel anyway. > > Right, but if the read or write don't need to block the UI thread, why > should they? I didn't say they should, rather the opposite. Maybe I wasn't entirely clear: They would be executed in parallel even with the single lock approach. Emacs would handle each event in a different thread (using a thread pool, probably, since starting threads often aren't cheap) so that the main thread always remains idle and can respond to new events. Due to the single lock, there would still be no concurrency problems in code that isn't adapted. It's just a matter of reviewing the most important places doing blocking I/O and turn on unlocked operation there (if it isn't turned on by default). Note that only the actual system call is run unlocked, so no surrounding C or elisp code needs to be adapted with locks. What needs to be done in the review is to add code that rechecks the state afterwards and fails gracefully if it has changed too much. A nice thing is that this is opt-in; there's no need to go through and thread safe everything - even if it only is enabled in a few common places there's an improvement in responsiveness.