Re: Concurrency via isolated process/thread

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> I do not plan to slow down access to PT.
> The basic idea is to have
> #define PT (current_thread->m_pt + 0)
> #define PT_BYTE (current_thread->m_pt_byte + 0)
>
> Basically, use thread object slot instead of buffer object slot to store
> point and restriction. This will not cause any performance degradation
> and allow multiple points in the same buffer.

No matter where thread local points are stored, each of these points
will need to be a marker, because text editing operations will otherwise
cause PT in other threads to be desynchronized with PT_BYTE within
multibyte buffers.  Both unibyte buffers and multibyte buffers will also
experience complications if a thread deletes text within a buffer,
reducing its size below point within another thread.

Each text editing operations must then loop through and update each of
these markers.

> What may be slightly slower is setting/getting points in other (not
> current) buffers.
> We will need to store point and restriction history for each thread.
> Searching this history will scale with the number of buffers that have
> been current previously during thread execution (though we may use hash
> table if necessary).
>
> However, accessing and changing point in buffer that is not current is
> not very common. AFAIU, it is done in (1) read operation when reading
> from stream represented by a buffer; (2) when switching buffers when we
> need to transfer current PT to history for current buffer and retrieve
> PT from history for the buffer that will become current.

See above.  What you are proposing is a fundamental change to the
performance attributes of some of the most basic operations performed by
Emacs, and is not acceptable.

> I propose to remove buffer points completely and use thread points
> instead.

IMHO, any change that increases the number of objects that store points
will be a mistake.  There is only one buffer, but there can be many
threads.