From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Mon, 31 Jan 2011 16:46:22 +0000 Message-ID: <4D46E75E.7080503@harpegolden.net> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1296492934 10356 80.91.229.12 (31 Jan 2011 16:55:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 Jan 2011 16:55:34 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 31 17:55:29 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 1Pjx2E-0000sz-2T for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 17:55:26 +0100 Original-Received: from localhost ([127.0.0.1]:38544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pjx2D-0006Yi-I7 for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 11:55:25 -0500 Original-Received: from [140.186.70.92] (port=60480 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjwtY-0001tr-3x for emacs-devel@gnu.org; Mon, 31 Jan 2011 11:46:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PjwtW-0001FE-OX for emacs-devel@gnu.org; Mon, 31 Jan 2011 11:46:27 -0500 Original-Received: from harpegolden.net ([65.99.215.13]:40130) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PjwtW-0001Eo-J7 for emacs-devel@gnu.org; Mon, 31 Jan 2011 11:46:26 -0500 Original-Received: from [87.198.55.208] (87-198-55-208.ptr.magnet.ie [87.198.55.208]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTPSA id 8E957683D1 for ; Mon, 31 Jan 2011 16:46:24 +0000 (GMT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 65.99.215.13 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:135319 Archived-At: On 31/01/11 14:29, Tom Tromey wrote: > One easy one is whether a new thread should inherit thread-local > bindings from its parent thread. Our initial implementation did > inherit, but later I found out that this is not common in the Lisp > world. I'd suggest going with CL afaik-now-most-common-practice and not inherit. Isn't that easier implementation-wise anyway? General api similarity to CL bordeaux-threads if doing conventional threads seems reasonable - I haven't thought especially deeply about it, but I doubt emacs lisp needs are particularly different to CL, and threading is no longer a new thing in CL land. You can see the bordeaux threads api documentation without diving into any implementation source code (the reference implementation's license is open, but anyway): http://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation Because historically some CLs did one thing and others the other, you can see it recommends all bindings are redone anyway in portable code. Also note how recent bordeaux-threads' make-thread takes an initial-bindings alist arg though, that defaults to the local value of *default-special-bindings*. So not "simply" inheriting local let bindings doesn't mean you can't provide a mechanism for establishing some thread-local initial bindings that don't correspond to the globals when you do want to do that - in fact you'll ultimately probably *want* to have such a mechanism, some things are likely "naturally thread local". The current version of that spec for the aforementioned initial-bindings/*default-special-bindings* considers it an open question whether the binding forms are evaluated in the original or new thread, but I expect new thread makes more sense, and is what recent clisp does: http://clisp.sourceforge.net/impnotes/mt.html#make-thread (clisp also has symbol-value-thread, for accessing thread-local bindings). OTOH, maybe someone who's been writing multithreaded lisp recently might want to chime in...