Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> From: John Shahid <jvshahid@gmail.com>
> Date: Thu, 30 Aug 2018 16:15:57 -0400
> Cc: psainty@orcon.net.nz, gazally@runbox.com, emacs-devel@gnu.org
> 
> >> 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.
> 
> Yeah, but I'm not sure why the portion that is prompting the user should
> be switching buffers.

Well, for starters, every interaction with the user that involves the
minibuffer changes the current buffer to the minibuffer.  And there
are other, more complex situations.

> I am not sure I totally understand the impact of every field in that
> struct has on my proposal.  Speaking of signals, I think those should be
> re-emitted on the child thread stack.  For example, the response of the
> main thread can indicate the error symbol and data, which can be used in
> the child thread to raise/signal again.

We could do that, but this would make programs running in other
threads much more complicated to write and debug, I think.  The
advantage of the current implementation is its simplicity; I wouldn't
suggest to give up that simplicity without very good reasons.

> No, I am not proposing changing the architecture.  I was proposing to
> literally use pipes to communicate between the different threads.  In
> fact that doesn't have to be a pipe it could any implementation of a
> queue, as was proposed earlier.

We could emulate a queue in any number of Lisp data structures, but
that is not the central problem being discussed in this thread.  The
problem is not how to queue requests, the problem is how to handle
them, and how to arrange interaction with the user, i.e. the part
where the user types the responses.

> I am proposing something similar but taking advantage of the fact that
> threads are sharing the same memory space.  Similar in the sense of
> preferring using the existing communication primitives
> (e.g. `make-pipe-process' and `accept-process-output').

Those primitives are implemented around features that are not useful
with threads, I think.

> I sincerely apologize if what I'm being off topic or not helping this
> conversation.

No need to apologize, your messages certainly weren't off topic.

I do suggest to read the related code, so you understand better how
this stuff works.