Re: Patch for fields of `struct buffer'

[Stefan Monnier]

> Other ideas I have been considering:

> Instead of explicit locks, just let any symbol function as a lock, and
> have the locks hidden in the C code.  (Or an extension of this idea, let
> any Lisp object be a lock -- "Java style".)

As we discussed in the past, the first step is of course cooperative
threading, via context switches at I/O points, which is a "minor" tweak
to the current semantics (where we already have such switches but the
threads are nested, i.e. the main thread can only re-start once
the sub-thread (a process filter or sentinel) finishes).

If/when we'll get to finer grained concurrency, I think it makes sense
to use something that's as clean and high-level as possible: Elisp is
already slow and interpreted, so we can afford something "slow".

> Or, instead of the locks-and-condition-variables approach, go the CSP
> route and have channels and channel-select.  This idea is making a
> comeback, maybe it would fit well in Emacs Lisp.

Erlang-style concurrency is nice and clean, but I'm not sure it'll
integrate well with existing code which stomps over a global state all
the time.  This doesn't mean it won't work.  If we can make it work
something like "one agent per buffer" and turn `set-buffer' into a kind
of message maybe we could get some good results, but it seems tricky.

Threads and locks don't look too good: too low-level.  If we go in that
direction, then STM seems a lot more appealing.


        Stefan