[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>
- Re: Concurrency via isolated process/thread, (continued)
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/17
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/17
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/17
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/17
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/17
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/17
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread,
Ihor Radchenko <=
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Po Lu, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/25
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24
- Re: Concurrency via isolated process/thread, Eli Zaretskii, 2023/07/24
- Re: Concurrency via isolated process/thread, Ihor Radchenko, 2023/07/24