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: Mon, 08 Dec 2003 00:00:05 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <5bfzfwteru.fsf@lister.roxen.com> References: <87oevbes4h.fsf@emacswiki.org> <20031117040607.C6C5D79B72@server2.messagingengine.com> <877k19slxn.fsf@emptyhost.emptydomain.de> <5bsmjxtg7m.fsf@lister.roxen.com> <87he0cllwl.fsf@emptyhost.emptydomain.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1070838133 20496 80.91.224.253 (7 Dec 2003 23:02:13 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 7 Dec 2003 23:02:13 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Dec 08 00:02:09 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 1AT7uj-0000uL-00 for ; Mon, 08 Dec 2003 00:02:09 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AT7uj-0003IH-00 for ; Mon, 08 Dec 2003 00:02:09 +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 1AT8qx-0003an-II for emacs-devel@quimby.gnus.org; Sun, 07 Dec 2003 19:02:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AT8qn-0003aX-FV for emacs-devel@gnu.org; Sun, 07 Dec 2003 19:02:09 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AT8qH-0003U2-Bg for emacs-devel@gnu.org; Sun, 07 Dec 2003 19:02:08 -0500 Original-Received: from [194.52.182.190] (helo=mail.roxen.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AT8qG-0003Tw-Ti for emacs-devel@gnu.org; Sun, 07 Dec 2003 19:01:37 -0500 Original-Received: by mail.roxen.com (Postfix, from userid 52) id ED2B29AD0; Mon, 8 Dec 2003 00:00:09 +0100 (MET) Original-Received: from lister.roxen.com (lister.roxen.com [194.52.182.147]) by mail.roxen.com (Postfix) with ESMTP id D8B5D9A64; Mon, 8 Dec 2003 00:00:04 +0100 (MET) Original-Received: from mast by lister.roxen.com with local (Exim 3.36 #1 (Debian)) id 1AT7sj-0005N6-00; Mon, 08 Dec 2003 00:00:05 +0100 Original-To: Kai Grossjohann In-Reply-To: <87he0cllwl.fsf@emptyhost.emptydomain.de> (Kai Grossjohann's message of "Sun, 07 Dec 2003 14:53:14 +0000") 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:18525 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18525 Kai Grossjohann wrote: >>> I made the suggestion to "just" let the implementor of the new thread >>> code worry about such things: if you start a new thread then you're >>> responsible for letting it run code that doesn't access globals in >>> problematic ways. >> >> Would a thread like that be used from the elisp level? > > That was my idea. I think a very sound design principle is to keep apart errors on different implementation levels. I.e. bugs on a higher level shouldn't have effects on a lower. E.g. if you make an elisp error, say moving the point and changing the same buffer from two threads, you shouldn't get an internally inconsistent buffer state which likely will cause Emacs to dump core later on or disbehave in subtle ways (maybe some markers get lost and simply cease to be kept up-to-date). The elisp programmer would have a hard time tracking down an error like that, and would probably report it as a bug in the core instead. Another problem related to that is that the elisp programmer would need to have extensive knowledge of the internals to know what would be safe to do. For instance, all buffers are linked together, which means there would probably be a race simply creating a new buffer from a thread. That's not obvious to the elisp programmer - buffers appear to be independent entities in elisp. Also, it wouldn't only be a matter of adding a `create-thread' elisp function and leave the rest to the elisp hacker. It'd still be necessary to do away with the global state used directly by the interpreter, e.g. the binding environment (which I've gathered is global now). I.e. potentially a lot of global variables would have to be moved to some thread state struct, and all the code that access them must be updated accordingly. Something similar would of course be necessary for the single lock solution too, but in that case it would suffice to have swap functions that copies and restores the global state from a thread state struct, so the code that uses global variables wouldn't have to be changed. I also suspect the garbage collector would be a problem if it isn't inherently thread safe. It probably needs to have a lock that excludes all other activities while it runs.