Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> From: John Shahid <jvshahid@gmail.com>
> Cc: psainty@orcon.net.nz, gazally@runbox.com, emacs-devel@gnu.org
> Date: Thu, 30 Aug 2018 12:08:32 -0400
> 
> > I'm afraid there's too much to encapsulate.  E.g., every buffer-local
> > variable in every buffer to be used by the thread will need to be
> > encapsulated; and how will the main thread know in advance all that?
> 
> Why do we need buffer local variables for all the buffers ?

Not all the buffers, only those which the thread function will make
current at some point.  Surely, you've seen and written code that
switches buffers as part of doing whatever it needs.

> Isn't the current buffer during the prompt the only relevant buffer.

No, it is not.  There are also various other parts of the global state
that should be specific to a thread, like the list of condition-case
handlers; see the members of 'struct thread_state' as it is defined
now, for more examples.

> My idea, is that each thread is started with a pipe which is used to
> interact with the main thread when it needs to prompt the user.

If you mean literally a pipe, then does this mean you suggest that
Emacs forks itself and runs each thread in a separate process, talking
via pipes with other processes?  That's a completely different
architecture from what we have now, and it wasn't my intent to discuss
such a complete rewrite of the concurrency code.

If this is not what you mean, please clarify what you mean by "pipe"
in this context.

> The child thread write the lambda that needs to run on the main
> thread then wait for main thread response using
> `accept-process-output'.  The main thread handles the request in the
> process filter displaying the prompt and writing the result back to
> the pipe. Since the child and main thread are sharing the same
> memory, the communication can simply be the symbol name that holds
> the closure and the response, respectively.

We already have the async package written by John Wiegley; it sounds
like you are describing the idea which he already implemented.

The limitation of this is that you need to communicate to much of a
state to the subordinate Emacs, and some stuff is very hard, sometimes
impossible, to share this way.

In any case, let's stay in the framework of the current basic design
of how threads work in Emacs.

Thanks.