Re: Concurrency via isolated process/thread

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Any async thread should expect that current buffer might be modified.
>
> That's impossible without rewriting a lot of code.  And even after
> that, how is a thread supposed to "expect" such changes, when they can
> happen at any point in the Lisp program execution?  What kind of
> measures can a Lisp program take to 'expect" that?  The only one that
> I could think of is to copy the entire buffer to another one, and work
> on that.  (Which is also not fool-proof.)

>> Of course, such write locks should happen for short periods of time to
>> be efficient.
>
> How can this be done in practice?  Suppose a Lisp program needs to
> access some object, so it locks it.  When will it be able to release
> the lock, except after it is basically done?  because accessing an
> object is not contiguous: you access it, then do something else, then
> access it again, etc. -- and assume that the object will not change
> between successive accesses.  If you release the lock after each
> individual access, that assumption will be false, and all bets are off
> again.

This is just a basic problem with any kind of async code. It should
either (1) lock the shared object it works with to prevent async writing
(not async reading though); (2) copy the shared object value and work
with the copy; (3) Design the code logic taking into account the
possibility that any shared object might change any time.

All 3 approaches may be combined.

>> Or lock the buffer for text modifications explicitly (the feature we
>> should probably provide - something more enforcing compared to
>> read-only-mode we have now).
>
> Locking while accessing a buffer would in practice mean only one
> thread can access a given buffer at the same time.  Which is what I
> suggested to begin with, but you said you didn't want to give up.

Not necessary. Multiple threads may still read the buffer in parallel,
except special case when read also involves moving the gap (being
written at low level). Or are you saying that moving the gap by read
primitives is common?

>> So, any time we need a guarantee that an object remains unchanged, we
>> should acquire object-specific write-preventing mutex.
>
> So we will allow access to many/all objects to only one thread at a
> time.

Only when modifying global objects by side-effect. Like `setcar' or
`move-marker', or `puthash' (on shared objects). And only for the
duration of that modification.

I do not think that "many/all" objects will be locked in practice.

Symbol objects will be treated separately, with value slot storing
multiple values for different threads. (This is necessary because of how
specpdl and rewind works for symbols)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>