Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> From: hw <hw@adminart.net>
> Cc: psainty@orcon.net.nz,  gazally@runbox.com,  rms@gnu.org,  emacs-devel-bounces+psainty=orcon.net.nz@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 27 Aug 2018 06:33:39 +0200
> 
> > We all but agreed that threads should not "fight" one another.
> 
> When you don't want threads to have to fight over the mini-buffer, each
> thread needs its own.

Not necessarily: we could serialize the interactions.

> If that would be done, each mini-buffer would need its own history so
> users can look at it to remember what they were doing --- I think that
> was mentioned.
> 
> Do you want to do that?

It doesn't seem to solve the problem: Emacs still has to decide which
minibuffer to use when.  And if you want to put that onus on the user,
then that same user could instead switch to thread N in the single
minibuffer we have now.

> How about: Emacs does not make this decision and does not let threads
> interact with users in this manner.  It puts all requests for input onto
> the queue unless it can clearly determine that the request is directly
> related to what the user is doing or working with.

Then the problem becomes how to manage that queue, and which part of
Emacs will do that.  We are back to the same issue, just in a slightly
different form.

> What you seem to think you must do --- grant an arbitrary thread access
> to the mini-buffer --- is what you *must not* do.

But in that case everything becomes sequential again, and we gained
nothing by introducing concurrency into Emacs.  The only threads that
will be able to run non-sequentially are those that never need to tell
the users or ask them anything, and that makes this feature rather
limited, I think.