[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch for fields of `struct buffer'

From: David De La Harpe Golden
Subject: Re: Patch for fields of `struct buffer'
Date: Mon, 31 Jan 2011 22:08:19 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101226 Icedove/3.0.11

On 31/01/11 19:04, Tom Tromey wrote:
"David" == David De La Harpe Golden<address@hidden>  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.)

FWIW - turns out the initial model in SBCL was inherit, but a transition to non-inherit was made in late 2005 at SBCL 0.9.6 [1][2]. ISTR more wide-ranging discussions of the issue elsewhere, but this seems to be the relevant sbcl-devel thread:

"[sbcl-devel] dynamic variables and threads" on 2005-10-12

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 do think that some message-passing type system is a nice high-level model, even in the multithreading case rather than multiprocessing. But isn't that something one might then build on top given the lowlevel pthredy stuff? I suppose you could not fully expose the lowlevel stuff to lisp.

[1] http://www.sbcl.org/manual/Special-Variables.html#Special-Variables
[2] http://www.sbcl.org/all-news.html#0.9.6

reply via email to

[Prev in Thread] Current Thread [Next in Thread]