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: Patch for fields of `struct buffer' Date: Sun, 06 Feb 2011 19:34:51 -0700 Message-ID: References: <4D46E75E.7080503@harpegolden.net> <4D47E65E.1030901@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1297046109 31656 80.91.229.12 (7 Feb 2011 02:35:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 7 Feb 2011 02:35:09 +0000 (UTC) Cc: emacs-devel@gnu.org, David De La Harpe Golden To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 07 03:35:04 2011 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 1PmGwR-0000dd-Vu for ged-emacs-devel@m.gmane.org; Mon, 07 Feb 2011 03:35:04 +0100 Original-Received: from localhost ([127.0.0.1]:56854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmGwR-0005lT-5S for ged-emacs-devel@m.gmane.org; Sun, 06 Feb 2011 21:35:03 -0500 Original-Received: from [140.186.70.92] (port=49580 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmGwM-0005l1-EL for emacs-devel@gnu.org; Sun, 06 Feb 2011 21:34:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmGwL-0007eb-75 for emacs-devel@gnu.org; Sun, 06 Feb 2011 21:34:58 -0500 Original-Received: from mx1.redhat.com ([209.132.183.28]:20843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmGwL-0007eV-0S for emacs-devel@gnu.org; Sun, 06 Feb 2011 21:34:57 -0500 Original-Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p172Yr0R017994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 6 Feb 2011 21:34:53 -0500 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p172Yq71024541; Sun, 6 Feb 2011 21:34:53 -0500 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 p172YqA1009705; Sun, 6 Feb 2011 21:34:52 -0500 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id B081A378307; Sun, 6 Feb 2011 19:34:51 -0700 (MST) X-Attribution: Tom In-Reply-To: <4D47E65E.1030901@gmail.com> (Daniel Colascione's message of "Tue, 01 Feb 2011 02:54:22 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 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:135664 Archived-At: >>>>> "Daniel" == Daniel Colascione writes: Tom> Instead of explicit locks, just let any symbol function as a lock, and Tom> have the locks hidden in the C code. Daniel> While elegant, I'm afraid using symbols as locks would lead to a Daniel> proliferation of locks of code, not data. Using a symbol as a big global Daniel> lock is easier than using gensym to get per-object locks. I don't really understand this. I think it doesn't matter, though, since after thinking about it some more, I think that it at least makes sense to want to lock buffers. Tom> (Or an extension of this idea, let Tom> any Lisp object be a lock -- "Java style".) Daniel> This approach has potential. I believe JVMs get away with this trick at Daniel> a cost of a machine word per object --- that's a big addition to a Daniel> simple cons cell, of which Emacs has quite a few. Modern JVMs don't pay anywhere near this price. JVM developers noticed a long time ago that most object's locks are never acquired, and that those that are acquired are usually uncontended, and optimized their implementations accordingly. If we went the "lock anything" route, I would suggest a weak hash table for locks, instead of putting the lock into the object. Tom