Re: Patch for fields of `struct buffer'

[David De La Harpe Golden]

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...