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 23:05:37 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5bhe0gdyry.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> <5bk75ce8p1.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 1070575692 21351 80.91.224.253 (4 Dec 2003 22:08:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 22:08:12 +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 23:08:07 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 1AS1dn-0004Fd-00 for ; Thu, 04 Dec 2003 23:08:07 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AS1dg-0005jW-00 for ; Thu, 04 Dec 2003 23:08:06 +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 1AS2b0-0002Fr-9c for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 18:09:18 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AS2aB-0001o0-7o for emacs-devel@gnu.org; Thu, 04 Dec 2003 18:08:27 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AS2Za-0001Z3-UE for emacs-devel@gnu.org; Thu, 04 Dec 2003 18:08:22 -0500 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AS2Yy-0001Hj-9o; Thu, 04 Dec 2003 18:07:13 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id 11DA49A3B; Thu, 4 Dec 2003 23:05:44 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id E334C9A0E; Thu, 4 Dec 2003 23:05:36 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1AS1bN-0006ro-00; Thu, 04 Dec 2003 23:05:37 +0100 Original-To: David Kastrup In-Reply-To: (David Kastrup's message of "04 Dec 2003 20:26:28 +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:18399 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18399 David Kastrup wrote: > The whole proposal was geared towards parallel execution of > computation-intensive tasks (like gnus summarizing and scoring) with > the editing foreground task. This discussion thread has been both about how threading should be solved and what should be achieved with the solution. True parallel execution is not the only discussed goal. In my opinion that goal is fairly unimportant - the big win is instead to be able to use the thread paradigm which in some cases is more convenient than the alternative, i.e. callback driven programming. As for the problem with Gnus, a threading model with a global lock is a worthwhile improvement: It would allow that cpu intensive process to be interrupted regularly to let Emacs respond to user actions. The big win here is imho that Emacs remains responsive; it doesn't bother me at all that the few milliseconds of work to achieve that is added to the total time of the score buffer generation instead of being carried out on another cpu. The issue of preemption at the elisp level only affects what kind of changes need to be done in Gnus to achieve these regular interrupts: If there is no preemption, regular yield calls have to be added at points where the state is consistent enough. Otherwise proper locking has to be implemented. > Cooperative yielding can't make use of hyperthreading. Yes it can. Seems to me you are confusing cooperative yielding and preemption with the use of a single global lock. A single global lock prohibits both parallel execution and underlying preemption. Preemption/cooperative yielding doesn't say anything about the kind of locking being used. > Tasks that require cooperative yielding must not share any resources > with any other task in between synchronization points (yield points, > whatever). Depends on what you mean with sharing a resource. To be precise, they can't leave any shared resource in an inconsistent state across a yield point, and they can't assume anything about the state of any shared resource afterwards. Of course, even in a cooperative environment mutexes are useful to lock out other threads from a resource that potentially is shared but that the current thread want to retain exclusive access to. > And even with cooperative multitasking you need separate stacks for > several resources, for every task, /.../ Of course. That's one of two things a thread consists of (the other is a promise of future cpu time). >> 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? > > I don't see any usefulness at all. Certainly every nontrivial task > will need to use the interpreter? So where is the gain? Blocking operations, like waiting on a mutex or reading from a file or socket, can leave the interpreter free to do other things. All blocking operations can be fixed to not need direct access to the interpreter data. In many cases it's such blocking operations that make Emacs unresponsive. The alternative to threads is to rewrite all such code to use callbacks (and in some cases the OS doesn't even provide the necessary interface for callbacks, e.g. gethostbyname(3)).