Re: Concurrency via isolated process/thread

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Sun, 09 Jul 2023 14:16:31 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> So, redisplay will have access to correct local values.
> >
> > No, it won't, because redisplay runs only in the main thread,
> > remember?  So it will not see changes to Vfoo done by other threads.
> > This could sometimes be good (e.g., if the changes are temporary), but
> > sometimes bad (if the changes are permanent).
> 
> If redisplay is about to display buffer that is being modified
> (including its buffer-local values), it will have to lock until the
> modification is done. Same for global Lisp variables.

Here goes one more advantage of concurrency, then: while redisplay
runs, all the threads that access buffers shown on display will have
to block.

> >> > What do you expect redisplay to do when some thread moves point in a
> >> > way that it is no longer in the window?
> >> 
> >> Async threads will not trigger redisplay. And they will have their own
> >> PT, BEGV, and ZV.
> >
> > This goes back to the other sub-thread, where we discussed how to show
> > and prompt the user from non-main threads.  The conclusion was that
> > there is no good solution to that.  The best proposal, wait for the
> > main thread, would mean that stuff like stealth fontifications, which
> > currently run from timers, cannot be run from a thread.
> 
> May you provide a link?
> I am not sure how independent PT+buffer in different threads affects
> prompts.

No, I meant the "Async threads will not trigger redisplay" part.