From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giuseppe Scrivano Newsgroups: gmane.emacs.devel Subject: Re: multi-threaded Emacs Date: Fri, 12 Dec 2008 20:03:25 +0100 Message-ID: <8763lp8bcy.fsf@master.homenet> References: <87abbiody1.fsf@master.homenet> <87ej0qci8g.fsf@master.homenet> <87y6yxm7xr.fsf@master.homenet> <87hc5gyn9x.fsf@master.homenet> <87ej0ixx97.fsf@master.homenet> <86skouwz8u.fsf@lifelogs.com> <86tz9asgdv.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1229108636 26001 80.91.229.12 (12 Dec 2008 19:03:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2008 19:03:56 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 12 20:04:58 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LBDJp-0000LO-AS for ged-emacs-devel@m.gmane.org; Fri, 12 Dec 2008 20:04:58 +0100 Original-Received: from localhost ([127.0.0.1]:45109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBDId-0004B4-Ue for ged-emacs-devel@m.gmane.org; Fri, 12 Dec 2008 14:03:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBDIZ-00049n-AX for emacs-devel@gnu.org; Fri, 12 Dec 2008 14:03:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBDIX-00048l-Qv for emacs-devel@gnu.org; Fri, 12 Dec 2008 14:03:39 -0500 Original-Received: from [199.232.76.173] (port=33024 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBDIX-00048g-Ls for emacs-devel@gnu.org; Fri, 12 Dec 2008 14:03:37 -0500 Original-Received: from jack.mail.tiscali.it ([213.205.33.53]:48773) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBDIW-00074R-Kv for emacs-devel@gnu.org; Fri, 12 Dec 2008 14:03:37 -0500 Original-Received: from master.homenet (84.223.201.253) by jack.mail.tiscali.it (8.0.022) id 48F7481002D781B9; Fri, 12 Dec 2008 20:03:32 +0100 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1LBDIL-0001v3-AC; Fri, 12 Dec 2008 20:03:25 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 11 Dec 2008 15:53:07 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:106848 Archived-At: Stefan Monnier writes: > Yes, that makes sense. Hopefully, most functions are "safe" in > this respect. > > BTW, implementing "atomically" is not necessarily that hard. > > Of course, it can be implemented with an "optimistic locking" discipline > where we track changes and undo them if the transaction aborts, but > until we get there, there are meny much simpler implementations which > will be useful. A first implementation is > > (defmacro atomically (&rest body) > `(let ((inhibit-thread-switch t)) > ,@body)) > > A better one, yet still trivial, is > > (defconst the-lock (make-lock)) > (defmacro atomically (&rest body) > `(progn > (lock-grab the-lock) > (unwind-protect > (progn ,@body) > (lock-release the-lock)))) > IMHO the first is the better solution for a cooperative model. There is only a thread active at a time, introduce lock/unlock can easily cause deadlocks, at least for the current threads scheduler implementation. We will need lock/unlock when we will use parallel threads and we must protect critical sections. Personally, I would avoid to introduce `atomically' now with a cooperative model but I prefer instead an explicit `yield'. In this way Elisp packages that use `yield' can benefit of threads and at the same time it will not break old packages designed to work with a single thread. Using `atomically' and hidden `yield's all around can break old packages that don't know about threads. On the other hand, my wish is to have an Emacs with parallel threads someday, surely it will needs explicit threads synchronization and `atomically' must be introduced in any case. It will break any Elisp package that doesn't use where it is needed. If we introduce it now, Elisp packages will probably work well later too. These are the advantages/disadvantages we will have choosing explicit yield or using atomically to inhibit thread switches. After all it is just choose when "cause" problems in Elisp packages, now with cooperative threads or later with parallel ones. What do you think? Do you want to have `atomically' now? Regards, Giuseppe