From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Are there plans for a multi-threaded Emacs? Date: Wed, 03 Dec 2003 12:58:56 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <4nllpt3hr3.fsf@lockgroove.bwh.harvard.edu> References: <87oevbes4h.fsf@emacswiki.org> <20031117040607.C6C5D79B72@server2.messagingengine.com> <87ekvpx18d.fsf@emptyhost.emptydomain.de> <4nad6cikxy.fsf@holmes.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 1070474541 30145 80.91.224.253 (3 Dec 2003 18:02:21 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 3 Dec 2003 18:02:21 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Dec 03 19:02:18 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 1ARbKL-00055e-00 for ; Wed, 03 Dec 2003 19:02:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARbKB-0002tC-00 for ; Wed, 03 Dec 2003 19:02:17 +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 1ARcGs-0002Tz-Jb for emacs-devel@quimby.gnus.org; Wed, 03 Dec 2003 14:02:46 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1ARcGS-0002ST-Mk for emacs-devel@gnu.org; Wed, 03 Dec 2003 14:02:20 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1ARcFv-0002On-95 for emacs-devel@gnu.org; Wed, 03 Dec 2003 14:02:19 -0500 Original-Received: from [80.91.224.249] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1ARcFu-0002Oh-PV for emacs-devel@gnu.org; Wed, 03 Dec 2003 14:01:46 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ARbIS-0005Tb-00 for ; Wed, 03 Dec 2003 19:00:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1ARbIP-0005TT-00 for ; Wed, 03 Dec 2003 19:00:17 +0100 Original-Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1ARbIP-0007lR-00 for ; Wed, 03 Dec 2003 19:00:17 +0100 Original-Lines: 43 Original-X-Complaints-To: usenet@sea.gmane.org X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Cancel-Lock: sha1:rHi73dDgzgdD0d75BBzclF/zpDo= 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:18330 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:18330 On Wed, 03 Dec 2003, rms@gnu.org wrote: > I think migrating Emacs towards a threading model is possible: > > - start with all primitive or ELisp functions assumed NOT > thread-safe > > - allow threads to run, but any access to a function needs to be > synchronous. At first, this will effectively make threads > simple switched tasks, and will probably make Emacs slower. > > Many sections of Lisp code would need to have locking in order > to run correctly with multiple threads. For instance, everything > of the form > > (setq global-list (cons foo global-list)) > > would need locking. What I proposed is that *all* functions start with the "synchronous" atribute. This would apply to primitives as well. Then, they would be gradually rewritten. For instance, a thread-safe setq would act just like the regular setq, but it would lock its arguments with semaphores before modifying them. The thread-safe setq can then be marked "asynchronous." To deal with the example above, all buffers, variables, processes, etc. that a synchronous function affects will have to be thread-locked also. So that needs to be an extension to my earlier definition of "synchronous" - not only should concurrent copies of the same function be forbidden, but also any objects that are used elsewhere need to trigger thread-locking while the function is in a scope that involves those objects. I don't know how feasible that is. Eventually pieces of code like the above would need to be rewritten using atomic functions in order to avoid these problems. For instance, (push foo global-list) would work better above because the push function can be made thread-safe. I know push is not the perfect example, but the point is that atomic modifications need to be done atomically. Ted