Re: advice needed for multi-threading patch

[Tom Tromey <tromey@redhat.com>]

Stefan> Removing locks sounds like a wonderful solution, but it's dangerous.
Stefan> I think you understand the danger and refer to it as "the bindings
Stefan> problem".  But since I'm not sure I'll state what I think is the
Stefan> problem:

Yes.  I forgot to write something important in that message, which is
what I think should happen.

Stefan> thread T1 goes into buffer B and does a dynamic let-binding of
Stefan> buffer-local variable X with value V1, then thread T2 does the same
Stefan> thing with value V2.
Stefan> What should that mean?

In my view, a let-binding should always be thread-local, and I think
buffer-localness shouldn't affect this.  This is enough of a rule to
answer your questions -- but it is just one choice, we could make
others, I suppose.

The primary reason I like this particular choice is that it seems least
susceptible to races when running ordinary lisp code in parallel.  Also,
it is simple to understand and consistent with the behavior of
non-buffer-local let-bindings.

Stefan> You have to consider those cases and then look at existing code and see
Stefan> what that code would expect.  A good variable to start with is probably
Stefan> default-directory (one of the most common buffer-local-and-let-bound
Stefan> variables I know of), but others need to be considered as well (I'm not
Stefan> sure they'll all agree on the behavior they expect).

I don't think existing code could have an expectation, simply because
existing code can't run multi-threaded.  The closest thing are process
filters, but I am not so sure that they are a good analogy in this case.

There are some oddities implied by making buffer-local let-bindings also
be thread-specific.  For example, some buffer-locals affect redisplay,
so what the user sees will depend on the thread in which redisplay is
run.

Tom