From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: 04 Dec 2003 19:01:10 +0100 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> <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 1070560976 21499 80.91.224.253 (4 Dec 2003 18:02:56 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 18:02:56 +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:02:53 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 1ARxoT-0002y6-00 for ; Thu, 04 Dec 2003 19:02:53 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARxoS-0002nP-00 for ; Thu, 04 Dec 2003 19:02:52 +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 1ARylU-0007cY-R3 for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 14:03:52 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARykz-0007NF-LR for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:03:21 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARykQ-00073d-N6 for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:03:18 -0500 Original-Received: from [62.226.11.218] (helo=localhost.localdomain) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1ARykL-00072I-8N for emacs-devel@gnu.org; Thu, 04 Dec 2003 14:02:41 -0500 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hB4I1BNa007302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2003 19:01:12 +0100 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id hB4I1Ahx007298; Thu, 4 Dec 2003 19:01:10 +0100 Original-To: Martin Stjernholm In-Reply-To: <5bptf4ebw8.fsf@lister.roxen.com> Original-Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:18389 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18389 Martin Stjernholm writes: > Ted Zlatanov wrote: > > >> o To be able to run several threads simultaneously in multicpu or > >> hyperthreaded systems. > >> o To get OS level preemption between threads. > > > > Those two benefits make a big difference. > > The last does not since it's quite feasible to simulate, as I've > outlined. (I know that from practical experience with this threading > model in a language environment fairly similar to elisp.) > > > Today's Pentiums have hyper-threading technology, so even a single > > processor can act as two. > > True. Hyperthreading is becoming more commonplace. > > > The best cooperative multitasking can't make use of multiple > > processors as well as premptive multithreading. > > I don't see how preemption per se can improve parallell execution. It's not preemption, but preemption aware coding, and it does not improve parallel execution but is a prerequisite for it. > 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. > 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. Relying on it might not be the best choice for such a feature, apart from the obvious problems with having two copies of Emacs with open buffers of their own around. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum