[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch for fields of `struct buffer'
From: |
Tom Tromey |
Subject: |
Re: Patch for fields of `struct buffer' |
Date: |
Sun, 06 Feb 2011 19:44:15 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
>>>>> "Stefan" == Stefan Monnier <address@hidden> 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
Re: Patch for fields of `struct buffer', Stephen J. Turnbull, 2011/02/01
Re: Patch for fields of `struct buffer', Stefan Monnier, 2011/02/01
- Re: Patch for fields of `struct buffer', Helmut Eller, 2011/02/01
- Re: Patch for fields of `struct buffer',
Tom Tromey <=
- Re: Patch for fields of `struct buffer', Tom Tromey, 2011/02/08
- Re: Patch for fields of `struct buffer', Helmut Eller, 2011/02/08
- Re: Patch for fields of `struct buffer', Tom Tromey, 2011/02/11
- Re: Patch for fields of `struct buffer', Helmut Eller, 2011/02/12
Re: Patch for fields of `struct buffer', Stefan Monnier, 2011/02/08
Re: Patch for fields of `struct buffer', Richard Stallman, 2011/02/01