Re: Patch for fields of `struct buffer'

[Tom Tromey]

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

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