[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch for fields of `struct buffer'

From: Helmut Eller
Subject: Re: Patch for fields of `struct buffer'
Date: Mon, 07 Feb 2011 09:05:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

* Tom Tromey [2011-02-07 02:44] writes:

>>>>>> "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.

How does a thread get the buffer in the first place?  In an Erlang-style
model a thread either has to create the buffer or receive it as a
message from an other thread.  Message passing could do some magic to
pass ownership: the receiver is the new owner of the buffer and the
sender loses ownership.  set-buffer would then check that the current
thread is the owner.  As a refinement we could have something like
"read-capability" and "write-capability".  Capabilities are also passed
with message passing.  A thread that has write-capability can modify the
buffer as usual.  Threads with read-capability can read the buffer but
this kind of reading--especially buffer properties or buffer local
variables--needs to copy the value (sometimes) to avoid sharing state.

Does that sound too complicated?

> 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.

Well, no mutable objects could be shared, which is quite different from
a lock; especially the case when somebody forgets to use the lock.

> I am interested in reasoned arguments, grounded in real Emacs code, to
> the contrary for either STM or CSP.

With some hand-waving, the current way to deal with external processes
can be seen as form of CSP.  Otherwise I'd say current Emacs code
neither uses STM nor CSP nor locks, which makes it hard to meet your


reply via email to

[Prev in Thread] Current Thread [Next in Thread]