Re: Concurrency via isolated process/thread

[Gregory Heytings <gregory@heytings.org>]

>
> while async threads will have to be written keeping in mind that global 
> variables may be changed during execution unless explicitly locked.
>
> And yes, we will need to implement locking on Elisp object level and 
> also on Elisp variable level.
>

It's not completely clear (to me) what you mean by "locking".  But I 
assume you mean two operations lock/unlock with which a thread can request 
and waive exclusive access to an object, and sleeps until that exclusive 
access is granted.  IOW, mutexes.  If my guess is correct, that is not 
possible.  You cannot use mutexes in a program whose data structures have 
not been organized in a way that makes the use of such synchronization 
primitives possible, without having deadlocks.  Given that in Emacs 
objects are part of an enormous unstructured graph, with pointers leading 
from anywhere to anywhere, that's clearly not the case, and all you can 
use is a single global lock.

But...

>
> But the very need to access global Elisp variables/objects from async 
> threads should not be considered a good practice (except near start/end 
> of thread execution). Most of processing should be done using threads' 
> local lexical scope.
>

... if what you have in mind are async threads that should in fact not 
access objects of the main thread, why is it necessary to lock objects? 
You can prepare the arguments to the async thread in the main thread, 
start the async thread, and when its execution completes process the 
return values of the async thread in the main thread, which is what 
emacs-async already does.

May I ask you if you have a concrete example of a task that you would like 
to perform with such threads, and that cannot already be done with 
emacs-async?  In other words, what are the limitations of emacs-async you 
try to overcome?