Re: Concurrency via isolated process/thread

[Po Lu <luangruo@yahoo.com>]

Ihor Radchenko <yantar92@posteo.net> writes:

> Another thread will have its own local set of Vfoo. When that thread
> switches to a buffer, it will update its local Vfoo values. So,
> redisplay will have access to correct local values.

How do you propose to associate different bindings for global variables
with each thread?  Remember that access to even a C variable in TLS is
significantly more expensive than an access to a normal variable; for
example, in MIPS systems, such an access results in an instruction
emulation trap to the Unix kernel, and on many other systems requires
multiple system and function calls.

Multiple value cells will have to be maintained for each symbol that is
locally bound.  This alone will already be very expensive; treating all
symbols this way is definitely unacceptable.

> Async threads will not trigger redisplay. And they will have their own
> PT, BEGV, and ZV.
>
> Basically, I propose async threads not to set buffer->pt in the buffer
> object. They will operate using their own local excursion and
> restriction.

We already have window points that are distinct from PT and PT_BYTE.
Adding thread-local points and narrowing would only contribute more to
the confusion.

The straightforward solution is rather for Lisp to avoid editing buffers
that are currently being displayed from outside the main thread.

>> Sure.  Like I said: we'd need to lock everything.

But the interlocking will be specific to the object being locked.  Two
threads will be able to modify the marker lists of two distinct buffers
simultaneously.