Re: Patch for fields of `struct buffer'

[Tom Tromey <tromey@redhat.com>]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

I couldn't think of a way to make this work, at least not with
`set-buffer' as the primitive.

I think it could be done by having all other buffer-manipulating
primitives (e.g., `insert') work by message-passing to some other
thread.  This is basically like a buffer lock.

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

I read up on STM and then spent some time thinking about it this
weekend.  I don't see how it could be implemented in Emacs without
extreme hairiness in the C code.  My thinking is along the lines of: a
transaction could conceivably touch any lisp object, including buffer
contents (I was thinking along the lines of: each call-interactively is
a transaction automatically).  So, any change anywhere would have to be
logged and then potentially rolled back if a transaction is aborted.

In particular, all heap modifications in the C code would need to be
intercepted... orders of magnitude uglier than my proposed `struct
buffer' patch.  (Though FWIW I have thought about this particular change
for other reasons -- you could introduce a software write barrier for
the GC this way :-)

Also I think heap reads would need to be intercepted and indirected to
make transactions not prematurely affect other threads.  So, this is
quite hard and inefficient.


I am interested in reasoned arguments, grounded in real Emacs code, to
the contrary for either STM or CSP.  Otherwise, sucky as it is, I think
the approach will be explicit locking.  I know I can make that one work
ok, or "ok enough".

After thinking about the Bordeaux threads model a bit more, I have come
to the conclusion that I would prefer something simpler.  E.g., if we
went "Java style" and only provided `with-lock-held' (and not separate
lock- and unlock- primitives), then we could eliminate a class of bugs.
Likewise, I think (and I know we already disagree here) that only having
recursive locks similarly eliminates a source of bugs.  I think these
issues are important because such bugs will show up to Emacs users in a
particular un-fun way.

Tom