From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Tue, 01 Feb 2011 02:54:22 -0800 Message-ID: <4D47E65E.1030901@gmail.com> References: <4D46E75E.7080503@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3AA047FBF33D4EF4DC961408" X-Trace: dough.gmane.org 1296557684 21141 80.91.229.12 (1 Feb 2011 10:54:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 10:54:44 +0000 (UTC) Cc: emacs-devel@gnu.org, David De La Harpe Golden To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 11:54:38 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 1PkDsb-00029i-OT for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 11:54:38 +0100 Original-Received: from localhost ([127.0.0.1]:48579 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkDsb-0007w7-0a for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 05:54:37 -0500 Original-Received: from [140.186.70.92] (port=47659 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkDsU-0007va-7T for emacs-devel@gnu.org; Tue, 01 Feb 2011 05:54:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkDsT-0004yd-3P for emacs-devel@gnu.org; Tue, 01 Feb 2011 05:54:30 -0500 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:36383) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkDsT-0004yH-0O for emacs-devel@gnu.org; Tue, 01 Feb 2011 05:54:29 -0500 Original-Received: by iyj17 with SMTP id 17so6946516iyj.0 for ; Tue, 01 Feb 2011 02:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type; bh=6/O88y0SxFpe44wl+L0m9mbXnZv4R3KhFPnWFv1DQjU=; b=h2uMBWs3ahPizdoXjM6jVlwvFUfnFoxymKapsOG5RCZ+LBPa25zAxL2O1vNTkFVbbU 65V2QTM9Dhyj3kj3ZJg+CcxbPZ3IyysNWH/g4EGmOAdqLl3TJThNj4xm7yxQa6tF+cL6 pN00Y76WdwT6miU6JG2Gq6HlHe7XXipGPOQMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=CBePOUStIJ/C7sJcFuONBNU3KJF877n1rcsEnk1SgCX2C6UkKLZaTXH9muiXExAzto 3Si5n0KNE7AH0/UWUuFzc5vKHZ61mgUXm3tW+wmTIp36ZtWDeQEBcVKCCo9E/CK2XTCf eIAOJ2AtKz74S0/6ZQl1fBm3DRvbF2fWsKH1Y= Original-Received: by 10.231.36.137 with SMTP id t9mr7894301ibd.195.1296557668149; Tue, 01 Feb 2011 02:54:28 -0800 (PST) Original-Received: from edith.local (c-67-183-23-114.hsd1.wa.comcast.net [67.183.23.114]) by mx.google.com with ESMTPS id i16sm18773785ibl.18.2011.02.01.02.54.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Feb 2011 02:54:27 -0800 (PST) User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 In-Reply-To: X-Enigmail-Version: 1.1.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 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:135395 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3AA047FBF33D4EF4DC961408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 1/31/11 11:04 AM, Tom Tromey wrote: > Other ideas I have been considering: >=20 > Instead of explicit locks, just let any symbol function as a lock, and > have the locks hidden in the C code. While elegant, I'm afraid using symbols as locks would lead to a proliferation of locks of code, not data. Using a symbol as a big global lock is easier than using gensym to get per-object locks. > (Or an extension of this idea, let > any Lisp object be a lock -- "Java style".) This approach has potential. I believe JVMs get away with this trick at a cost of a machine word per object --- that's a big addition to a simple cons cell, of which Emacs has quite a few. > Or, instead of the locks-and-condition-variables approach, go the CSP > route and have channels and channel-select. This idea is making a > comeback, maybe it would fit well in Emacs Lisp. Some sort of CSP facility would be interesting. I'd also love to see Clojure-style STM, although I don't know how well something like an agent would work in elisp's more imperative environment. Also, it'd require lexbind to make sense at all. --------------enig3AA047FBF33D4EF4DC961408 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1H5mEACgkQ17c2LVA10VsaJQCgupoo/HJRmHayALeLol5dghyy 0GoAn1hNeZ4vQXcW42RpaIdDBjFCCQb/ =Mlcu -----END PGP SIGNATURE----- --------------enig3AA047FBF33D4EF4DC961408--