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 00:00:18 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5bd6b4dw8t.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> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070578999 17997 80.91.224.253 (4 Dec 2003 23:03:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 4 Dec 2003 23:03:19 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Fri Dec 05 00:03:16 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 1AS2V9-0007zd-00 for ; Fri, 05 Dec 2003 00:03:15 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AS2V9-0006li-00 for ; Fri, 05 Dec 2003 00:03:15 +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 1AS3Qx-0000ar-0a for emacs-devel@quimby.gnus.org; Thu, 04 Dec 2003 19:02:59 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AS3QO-0000aT-5s for emacs-devel@gnu.org; Thu, 04 Dec 2003 19:02:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AS3Pr-0000TA-5E for emacs-devel@gnu.org; Thu, 04 Dec 2003 19:02:22 -0500 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AS3Pq-0000Sv-Fs for emacs-devel@gnu.org; Thu, 04 Dec 2003 19:01:50 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id D45819A3B; Fri, 5 Dec 2003 00:00:23 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id 060899A17; Fri, 5 Dec 2003 00:00:18 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1AS2SI-0006xN-00; Fri, 05 Dec 2003 00:00:18 +0100 Original-To: Ted Zlatanov In-Reply-To: <4nu14ggwvq.fsf@lockgroove.bwh.harvard.edu> (Ted Zlatanov's message of "Thu, 04 Dec 2003 15:18:17 -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:18402 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18402 Ted Zlatanov wrote: > Not all threads need to be aware of each other. Not all threads will > compete for the same resources. True, but these are arguments against a single lock. They have nothing to do with preemption and cooperative yielding. Imho the advantages of a single lock outweighs these. > Not all threads, in a cooperative setup, will cooperate with each > other due to programmer or design error. Indeed. As I've said earlier, this is already the situation today. Threads with cooperative yielding would provide a tool which I believe makes it fairly simple to solve these cases. Some changes are necessary, but otoh changes are necessary in the preemptive case too since proper locking needs to be implemented. > Also, I actually think it's easier to program for preemptive > multithreading because you write thread-safe code instead of > reengineering your code to fit the cooperative model. Well, it's just as much reengineering to thread safe existing code as to implement cooperative switching in it. Anyway, it's not really an either-or situation. Thread tools like mutexes are useful also in a cooperative environment. The difference is that there's more control of where thread switches can take place in the cooperative case. It's also possible to add a form like this: (auto-yield (while (big-task-not-finished) (work-on-big-task))) `auto-yield' would instruct the elisp interpreter to yield automatically inside the code block whenever it thinks it's time for it. I.e. you'd get preemption inside that specific code block. > Here's more examples: font-locking a buffer; reading or writing a > file. Reading or writing are blocking operations, so they would be executed in parallel anyway. Font locking is otoh cpu bound, but to get advantage of true parallelism you'd need a situation where you do font locking at the same time as something else that's cpu bound, e.g. Gnus scoring. Otherwise it works fine to interrupt it to do display updates and so on. > Heavyweight threads are a problem because, as I mentioned already, > Emacs is such a tightly coupled environment. I think lightweight > threads are better for performance. Yes, I don't think it'd be useful very often either. This is actually an argument against fine grained locking too: When much code contend for the same resources and those are covered by many small locks, much time will be spent in context switching due to outlocking.