Re: Patch for fields of `struct buffer'

[Tom Tromey <tromey@redhat.com>]

RMS> Your argument makes sense, for people using powerful machines.
RMS> I have a slow one, by today's standards, and I don't think it is
RMS> likely I will get a faster one (or multicore) for years if ever.
RMS> Many free software activists use the same machine for the same reason.

It is an empirical question as to whether this change slows things down
too much.  I don't think it is the case that any slowdown is
unacceptable.

One thing worth noting is that if the concurrency branch is a huge
failure, it is simple to back out at least the buffer change.  It can be
done with a perl one liner.  And, since there is no performance penalty
possible until concurrency is actually merged, I think the risks
associated with moving forward are rather low.

RMS> Meanwhile, the big problem of making Emacs work with true parallelism
RMS> is not in the general mechanisms.  It is in all the code that knows
RMS> it can only be interrupted due to an error or where it says QUIT.
RMS> If you want to test the feasibility of real parallelism, that's what
RMS> you need to work on.

The point of this patch series is to make it simpler to work on the
other problems on a branch.  Without the infrastructure in place,
merging (in either direction) is simply too difficult.  That is, it is a
stepping stone to getting cooperative threading, which itself is a
stepping stone to real parallelism.

Tom