Re: Concurrency via isolated process/thread

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> 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?
>
> See bug#64391 for a performance regression in Gnus resulting from a
> _single_ marker.

That's not a single marker. Quite far from it.

/* Record the accessible range of the buffer when narrow-to-region
     is called, that is, before applying the narrowing.  That
     information is used only by internal--label-restriction.  */
  Fset (Qoutermost_restriction, list3 (Qoutermost_restriction,
                                       Fpoint_min_marker (),
                                       Fpoint_max_marker ()));

will create a pair of __new__ markers every time it is called.
And, AFAIU, did not clear them all the way until the next GC.
So, the reproducer mentioned in the report was likely dealing with a
growing number of markers.

There is no doubt that processing markers takes time - Emacs goes
through the whole marker list on every buffer change. But it is
acceptable when the number of markers is moderate, not in the
pathological cases with huge number of markers.

Note, however, that it can (and probably should) be improved.
As discussed in the past, we can utilize itree.c to store markers and
remove the need in O(N_markers) processing when updating marker
positions.

>> 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.
>
> But Org doesn't run in another thread, does it?  Besides, text matching
> is hardly the only tasks our users want to perform in a different
> thread.

My point was to show that per-thread point can be quite useful. I did
not try to prove that all the possible tasks potentially done via
threads need it.

Text matching is one of the _common_ tasks when working with buffers,
don't you agree?

>> Point and restriction changing unpredictably is much bigger problem in
>> practice, because it can be triggered even without editing the buffer.
>
> Code that believes this is a problem should devise and make use of
> additional synchronization protocols independent from Emacs's internal
> buffer synchronization.

Please refer to my other message where I showed why synchronization is
extremely difficult with the available tools even for something as
simple as incremental regexp search.

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