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: Thu, 04 Dec 2003 19:31:22 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5bk75ce8p1.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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070563536 27094 80.91.224.253 (4 Dec 2003 18:45:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 18:45:36 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Dec 04 19:45:30 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 1ARyTi-0006CM-00 for ; Thu, 04 Dec 2003 19:45:30 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARyTh-0003Ib-00 for ; Thu, 04 Dec 2003 19:45:30 +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 1ARzPJ-00066r-5E for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 14:45:01 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARzLR-0004uy-3H for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:41:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARzKu-0004j6-5y for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:40:59 -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 1ARzKt-0004ia-8e for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:40:27 -0500 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by mx20.gnu.org with esmtp (Exim 4.24) id 1ARyGD-0006IX-0X; Thu, 04 Dec 2003 13:31:33 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 0EE5C9A1C; Thu, 4 Dec 2003 19:31:29 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 8545499E0; Thu, 4 Dec 2003 19:31:22 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1ARyG3-0006XW-00; Thu, 04 Dec 2003 19:31:23 +0100 Original-To: David Kastrup In-Reply-To: (David Kastrup's message of "04 Dec 2003 19:01:10 +0100") 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:18392 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18392 David Kastrup wrote: > It's not preemption, but preemption aware coding, and it does not > improve parallel execution but is a prerequisite for it. Maybe we have a terminology problem here. I don't regard thread yields due to blocking operations or cooperative yielding as preemption. Instead I reserve that term for uncooperative yielding when a time slice is up. It's perfectly fine to have several executing tasks in parallell without ever stopping any of them uncooperatively. >> Fine grained locking can, but it's hard to avoid making it too fine >> grained so that the locking itself becomes more time consuming than >> the speedup from the improved parallellism it achieves. > > For that reason it is important to have as few locks necessary as > possible. And having to lock on the binding table would be > prohibitively expensive. Another reason to have only a single interpreter lock and no preemption. It's hardly so expensive that it would take significant time compared to blocking operations, is it? >> Anyway, a way to cope with such heavy tasks could be to make it easy >> to fork a separate interpreter with its own data set. It would then >> only take the main interpreter lock explicitly and rarely to >> communicate its results and request new data, or perhaps even be >> restricted to communication through a pipe. > > `fork' is a system call that is not available for a considerable > number of Emacs runtime platforms. Sorry, I was not entirely clear. I meant only starting a new interpreter with its own data set in some suitable way, be it with a thread or a new process. The behavior of the unix fork(2) system call is actually not very suitable since the new interpreter should not have a copy of all the data in the original instance.