Re: Patch for fields of `struct buffer'

[Richard Stallman]

    Yes.  I think that is the right tradeoff given my long term goal, which
    is preemptive multi-threading.

I don't think preemptive thread switching is a sensible goal.  It is
so much trouble that it isn't worth doing even in the long term.
Thus, it is a mistake to do much work now, or complicate the code now,
or cause a slowdown now, for the sake of preemptive thread switching.

    Also, the cost from this patch (and its successor) only applies to
    DEFVAR_PER_BUFFER and DEFVAR_KBOARD variables.

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

Meanwhile, I am concerned about this:

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

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

    * Ordinary Lisp variables, not defined by C code.
      These will always involve an indirection through find_variable_location.
      However, ordinary Lisp variable access may already involve various
      indirections due to Lisp_Buffer_Local_Value, Lisp_Buffer_Objfwd, etc.

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

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

-- 
Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org