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.