emacs-devel
[Top][All Lists]
Advanced

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

Re: Concurrency via isolated process/thread


From: Ihor Radchenko
Subject: Re: Concurrency via isolated process/thread
Date: Mon, 24 Jul 2023 12:25:40 +0000

Po Lu <luangruo@yahoo.com> writes:

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

But editing operations already loop over all the buffer markers. If a
just dozen of extra buffer markers (one for each thread, in the worse
case) are unacceptable, we should really do something about marker
performance.

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

Last time I wrote a thread code that had to work with buffer text, I had
to store markers manually anyway. Otherwise, point position were always
chaotic.

And threads that will not work with buffer text, will only need to store
a single marker.

So, I do not see how the proposed approach will make things worse
memory-wise.

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



reply via email to

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