From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Concurrency Date: Mon, 29 Mar 2010 10:58:05 -0600 Message-ID: References: <27349166.post@talk.nabble.com> <4B756FB7.3050202@swipnet.se> <87k4ui4gik.fsf@lola.goethe.zz> <27566385.post@talk.nabble.com> <87wryi2sjd.fsf@lola.goethe.zz> <27585994.post@talk.nabble.com> <87k4ucdmwh.fsf@stupidchicken.com> <87d3zweq4e.fsf@master.homenet> <87y6hg1h4a.fsf@thor.thematica.it> <87tys3j9fa.fsf@lifelogs.com> <87eij6tqmu.fsf@lifelogs.com> <49707.130.55.132.67.1269807922.squirrel@webmail.lanl.gov> <87oci8rwtw.fsf@gnu.org> <87aatrigux.fsf@thor.thematica.it> <224F559B-6F4F-4EFB-855C-B35C7DA24731@raeburn.org> Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269882388 9056 80.91.229.12 (29 Mar 2010 17:06:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Mar 2010 17:06:28 +0000 (UTC) Cc: "emacs-devel@gnu.org discussions" To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 29 19:06:24 2010 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.69) (envelope-from ) id 1NwIO8-0006s6-C8 for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 19:06:23 +0200 Original-Received: from localhost ([127.0.0.1]:47777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwINs-0007Ag-Iw for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 13:04:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NwILB-0005el-3J for emacs-devel@gnu.org; Mon, 29 Mar 2010 13:01:29 -0400 Original-Received: from [140.186.70.92] (port=59534 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwIIP-0003qQ-1x for emacs-devel@gnu.org; Mon, 29 Mar 2010 13:01:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NwIIC-0003TU-Ow for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:58:26 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:64955) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwIIC-0003TK-HZ for emacs-devel@gnu.org; Mon, 29 Mar 2010 12:58:24 -0400 Original-Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2TGwNiF008321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Mar 2010 12:58:23 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2TGw6C2007919; Mon, 29 Mar 2010 12:58:12 -0400 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o2TGw59q001337; Mon, 29 Mar 2010 12:58:06 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 83577378185; Mon, 29 Mar 2010 10:58:05 -0600 (MDT) X-Attribution: Tom In-Reply-To: <224F559B-6F4F-4EFB-855C-B35C7DA24731@raeburn.org> (Ken Raeburn's message of "Mon, 29 Mar 2010 12:33:58 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:122856 Archived-At: >>>>> "Ken" == Ken Raeburn writes: Tom> I think it would be better to have all mutexes be recursive, because it Tom> is safer. Ken> I can see some desire for recursive mutexes, but I lean towards Ken> Butenhof's view myself. I realized later I should probably expand on this. The issue I have with non-recursive mutexes has to do with the nature of Emacs itself. First, there is a large body of existing elisp that we don't want to break. And, second, Emacs changes over time and it is very common to write backward compatibility hacks and the like to make elisp work with multiple versions. Finally, Emacs is not and will never be a high-performance environment. I think these issues imply that we should pick the safe option always. As a concrete example, consider the one existing user-visible mutex in Emacs right now: the minibuffer mutex. Lots of code, like yes-or-no-p, acquires and releases this mutex. But suppose you want to write a function that uses the minibuffer for a multi-step operation, and you want to use yes-or-no-p (or something else) as a subroutine. If you have recursive mutexes, no problem, just acquire the lock. If you don't have recursive mutexes, then all the primitives must be duplicated into -lock and -nolock variants; or, the primitives should do no locking and must be called with the lock held. I'm not a fan of the first option, since it means an explosion of functions. And the second option is also bad, because it breaks existing elisp. (FWIW I am not sure a minibuffer mutex is the right thing. It seems like this should be at least per-terminal.) Ken> If all mutexes are recursive, I'd like a Ken> way to find out if I've already got a mutex locked, so I can Ken> manually detect when I've screwed up my locking model, even if Ken> someone else wants to use recursive mutexes in their code. Ken> BTW, one extension I'd suggest is an optional timeout for Ken> mutex-lock These make sense to me. Tom