Re: Concurrency via isolated process/thread

[Ihor Radchenko <yantar92@posteo.net>]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> 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.
>
> It is unacceptable because it is drastically more expensive than it is
> today.  No degree of optimization to the marker code will eliminate this
> problem.

May you please elaborate?
I routinely deal with buffers having hundreds of markers.
How will adding a couple of markers from threads will make things worse?

>> 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.
>
> What happens if another thread deletes the text that surrounds point in
> the thread your code is running in?  Won't you have the same problem
> then anyhow?

Usually not. The worst case could be some match being skipped, which is
often acceptable. I have seen plenty of examples because Org provides
`org-element-map' API where we allow the user function to change buffer.

Point and restriction changing unpredictably is much bigger problem in
practice, because it can be triggered even without editing the buffer.

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