Re: Patch for fields of `struct buffer'

[Daniel Colascione]

On 2/1/11 8:41 AM, Richard Stallman wrote:
> Your argument makes sense, for people using powerful machines.
> I have a slow one, by today's standards, and I don't think it is
> likely I will get a faster one (or multicore) for years if ever.
> Many free software activists use the same machine for the same reason.

If you link against GNU Pth, the threading primitives become practically
free aside from the few hundred pointers referring to global Lisp
variables. I doubt the aggregate impact of following those indirections
would have much of an impact over all the pointer-chasing Lisp code
already performs. (How many cons cell are used for the output of
parse-partial-sexp?)

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

One approach successfully applied to other systems that make assumptions
about a lack of preemptive concurrency is to put large locks around the
sensitive portions and gradually split these locks up over time as the
code is improved. Subrs not specially marked as concurrency-safe could
be made to automatically take such a lock on entry, and Feval would
release it until another such subr were entered. Over time, more subrs
could be inspected and marked safe.

signature.asc
Description: OpenPGP digital signature