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: Mon, 31 Jan 2011 12:04:07 -0700 Message-ID: References: <4D46E75E.7080503@harpegolden.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1296500707 23286 80.91.229.12 (31 Jan 2011 19:05:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 Jan 2011 19:05:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: David De La Harpe Golden Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 31 20:05:03 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 1Pjz3f-0006pG-As for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 20:05:03 +0100 Original-Received: from localhost ([127.0.0.1]:55917 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pjz3d-0006OC-Ml for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 14:05:02 -0500 Original-Received: from [140.186.70.92] (port=40483 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pjz2r-0005xD-Aw for emacs-devel@gnu.org; Mon, 31 Jan 2011 14:04:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pjz2p-0007zz-Oq for emacs-devel@gnu.org; Mon, 31 Jan 2011 14:04:13 -0500 Original-Received: from mx1.redhat.com ([209.132.183.28]:36038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pjz2p-0007zp-DK for emacs-devel@gnu.org; Mon, 31 Jan 2011 14:04:11 -0500 Original-Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0VJ49F9030365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Jan 2011 14:04:10 -0500 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p0VJ49o8019251; Mon, 31 Jan 2011 14:04:09 -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 p0VJ48JU021353; Mon, 31 Jan 2011 14:04:08 -0500 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 03D073782CA; Mon, 31 Jan 2011 12:04:07 -0700 (MST) X-Attribution: Tom In-Reply-To: <4D46E75E.7080503@harpegolden.net> (David De La Harpe Golden's message of "Mon, 31 Jan 2011 16:46:22 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 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:135330 Archived-At: >>>>> "David" == David De La Harpe Golden writes: Tom> One easy one is whether a new thread should inherit thread-local Tom> bindings from its parent thread. Our initial implementation did Tom> inherit, but later I found out that this is not common in the Lisp Tom> world. David> I'd suggest going with CL afaik-now-most-common-practice and not David> inherit. Isn't that easier implementation-wise anyway? Not notably, especially since this code is already written. (I did notice a bug on the branch ... but whatever, it is easy to fix.) David> General api similarity to CL bordeaux-threads if doing conventional David> threads seems reasonable - I haven't thought especially deeply about David> it, but I doubt emacs lisp needs are particularly different to CL, and David> threading is no longer a new thing in CL land. ... David> http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation I am quite sympathetic to this idea, but at the same time, Emacs Lisp is not CL, so I think the field is more open. BTW, thanks for the pointer. I've been kicking around different ideas for how everything should fit together. The API at that URL is basically the "simple reflection of POSIX threads" model. Other ideas I have been considering: Instead of explicit locks, just let any symbol function as a lock, and have the locks hidden in the C code. (Or an extension of this idea, let any Lisp object be a lock -- "Java style".) 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. I welcome input on this topic. Tom