Re: Patch for fields of `struct buffer'

[Tom Tromey]

RMS> I don't think preemptive thread switching is a sensible goal.  It
RMS> is so much trouble that it isn't worth doing even in the long term.

I don't think it is nearly that bad.

RMS> That is more limited than I thought it was.  If it is needed for
RMS> non-preemptive thread switching, the benefit would justify the cost,
RMS> but I think it isn't needed for that.  If this is would only be needed
RMS> for preemptive thread switching, I think the loss of clarity and
RMS> naturalness of the code is enough reason not to do it.

Ok.  I will stop work on this patch, then.  I am not sure if I am
interested in working on threads done the other way, I will have to
think about it.

You might want to consider backing out my earlier patch.  It won't be
needed either.

Tom>     * DEFVAR_LISP and other true globals.
Tom>       These will be handled efficiently by using pointer tricks.  Each
Tom>       global will have a corresponding pointer to it, and each thread will
Tom>       have its own copy of all of these.

RMS> That is incorrect semantics.  Most ofthese values should be shared
RMS> between all the threads that don't bind them somehow, just as they
RMS> are shared between all the buffers that don't bind them.

I wasn't clear enough.

For each global variable, the per-thread pointer will ordinarily point
to the main thread's slot.  When the variable is let-bound, thus
becoming thread-local, the pointer will be redirected to the slot in the
per-thread structure.  When the outermost let-binding is undone, the
pointer will be reset to the main thread's slot.

I think this implements the correct semantics: a global variable's value
is shared between all threads, and a let-bound variable is thread-local.

RMS> Are you saying you would like to change it so that every access to
RMS> a Lisp variable requires indirecting?

Only potentially -- like today.

RMS> At present, every access to a Lisp variable requires a test for
RMS> possible indirections, but most variables don't have an indirection.

That will continue to be the case.  We can add another value to enum
symbol_redirect to indicate variables which are potentially
thread-local.

Tom