Re: Patch for fields of `struct buffer'

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Actually the long term goal is true concurrency, to make use of the
insane number of cores we'll have by them.

RMS> Moreover, it is a big change.  Why not use a mechanism like that of
RMS> buffer-local variables?  It would be much easier and perhaps
RMS> better.

I do not care too much about the mechanism itself.  What matters to me is:
- the semantics exposed to Elisp, whee the main qualities are
  cleanliness, compatibility with existing code, and compatibility with
  the future goal of concurrency.
- the changes to the code base.

To the extent that they're hidden behind macros, the current changes
seem fine (the move of vars to globals.h is not, tho, which is why
I want globals.h to be auto-generated).

> However, in the long run I would like to see preemptive threading.
> I would rather make decisions now that support this goal, and
> I believe that planning to do any work at all at thread-switch time is
> bad for this.

While I largely agree, I do not presume that the mechanism you use now
is necessarily going to stay.  So it's important that it stay
well encapsulated.


        Stefan


PS: BTW, the special Lisp_Object values like Lisp_Buffer_Local_Value have
disappeared on the trunk, replaced by extra bits in the Symbol objects.