Is automatic yield support feasible for threads?

Is automatic yield support feasible for threads?

[ndame via Users list for the GNU Emacs text editor]

AFAIK Emacs has cooperative threading, so a badly behaving thread can prevent UI updates, therefore if some costly operation is moved into a separate thread then the code has to be modified in order to yield periodically if the code doesn't do I/O.

If that's the case then what if the interpreter itself could support automatic yielding when some flag is set, so it could yield automatically after every several instructions?

For example, make-thread could have an optional argument specifying after how many instructions a thread-yield should be called automatically and if this argument is set then a global flag is set, so the interpreter knowns it should call yield regularly.

This automatic yielding would have some cost, but in return any code could safely be moved into a separate thread without the danger of locking up the UI if this optional argument is given to make-thread. So it could makes using cooperative threads easier.

Could such an automatic yield support be feasible for threads?

Re: Is automatic yield support feasible for threads?

[Philipp]

> Am 04.11.2021 um 18:10 schrieb ndame via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>:
> 
> AFAIK Emacs has cooperative threading, so a badly behaving thread can prevent UI updates, therefore if some costly operation is moved into a separate thread then the code has to be modified in order to yield periodically if the code doesn't do I/O.
> 
> If that's the case then what if the interpreter itself could support automatic yielding when some flag is set, so it could yield automatically after every several instructions?
> 
> For example, make-thread could have an optional argument specifying after how many instructions a thread-yield should be called automatically and if this argument is set then a global flag is set, so the interpreter knowns it should call yield regularly.
> 
> This automatic yielding would have some cost, but in return any code could safely be moved into a separate thread without the danger of locking up the UI if this optional argument is given to make-thread. So it could makes using cooperative threads easier.
> 
> Could such an automatic yield support be feasible for threads?

I don't think it's feasible.  Emacs Lisp code typically relies heavily on mutating global state (think buffer contents, the buffer list, `point', dynamic variables, ...), and normally doesn't put such state mutations into properly synchronized critical sections.  Yielding from such unprotected critical sections would result in very subtle bugs (`point' randomly moving around, corruption of internal data structures, buffers vanishing surprisingly, ...).

Re: Is automatic yield support feasible for threads?

[ndame]

On Tuesday, November 9th, 2021 at 3:53 PM, Philipp <p.stephani2@gmail.com> wrote:
>
> I don't think it's feasible. Emacs Lisp code typically relies heavily on mutating global state (think buffer contents, the buffer list, `point', dynamic variables, ...), and normally doesn't put such state mutations into properly synchronized critical sections. Yielding from such unprotected critical sections would result in very subtle bugs (`point' randomly moving around, corruption of internal data structures, buffers vanishing surprisingly, ...).

I don't think threads should be used for UI manipulation, that should be left for the main thread. Threads are more useful for longer running calculations, computations and those should have no problem if they work on local data.

But you are right if someone uses a thread for UI changes then there can be problems. My idea is about an _optional_ automatic yielding for threads, so it still could be useful for those threads which are self contained. Those could choose to start with periodic automatic yielding, so their code do not have to be sprinkled with manual yield calls, impacting code readability.

Re: Is automatic yield support feasible for threads?

[Eli Zaretskii]

> Date: Wed, 10 Nov 2021 07:46:48 +0000
> From: ndame <laszlomail@protonmail.com>
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> 
> But you are right if someone uses a thread for UI changes then there can be problems. My idea is about an _optional_ automatic yielding for threads, so it still could be useful for those threads which are self contained. Those could choose to start with periodic automatic yielding, so their code do not have to be sprinkled with manual yield calls, impacting code readability.

How can a thread be made to yield at some arbitrary point of its code
without risking problems?  E.g., a thread could be in the middle of
some operation that must be done atomically.

Re: Is automatic yield support feasible for threads?

[Philipp]

> Am 10.11.2021 um 08:46 schrieb ndame <laszlomail@protonmail.com>:
> 
> On Tuesday, November 9th, 2021 at 3:53 PM, Philipp <p.stephani2@gmail.com> wrote:
>> 
>> I don't think it's feasible. Emacs Lisp code typically relies heavily on mutating global state (think buffer contents, the buffer list, `point', dynamic variables, ...), and normally doesn't put such state mutations into properly synchronized critical sections. Yielding from such unprotected critical sections would result in very subtle bugs (`point' randomly moving around, corruption of internal data structures, buffers vanishing surprisingly, ...).
> 
> I don't think threads should be used for UI manipulation, that should be left for the main thread. Threads are more useful for longer running calculations, computations and those should have no problem if they work on local data.

There are two problems with that approach:
1. Emacs doesn't clearly separate UI work from non-UI work.  For example, buffers are primarily a UI feature, but are also widely used for string manipulation unrelated to any UI action, and such uses are typically considered implementation details.
2. There are many coding patterns involving global state mutations that are unrelated to UI actions, e.g., caching the result of an expensive computation.

> 
> But you are right if someone uses a thread for UI changes then there can be problems. My idea is about an _optional_ automatic yielding for threads, so it still could be useful for those threads which are self contained.

Only trivial thread bodies are guaranteed to be self-contained.  You'd need to audit every single function that the thread body calls whether it performs any unsynchronized global state mutations, which is infeasible since such state mutations are generally considered implementation details, and functions typically don't document them.