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 21:46:30 +0200
> 
> >> 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.
> 
> Users still require sequentiality to be able to deal with them.

Yes, but there's no way around 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.
> 
> true
> 
> And if you want neither Emacs to decide which prompts to interrupt the
> user with, nor let the user decide which prompts to deal with, you're
> kinda out of options.

I'd prefer Emacs to decide that.  My point above was that having
several minibuffers doesn't solve the basic problem, which is: how
should Emacs decide which of the threads' prompts gets submitted to
the user at any given time.  When we solve that basic problem, we
could talk about the details like whether this happens in the same
minibuffer or in several.

> > 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.
> 
> Aren't the threads already managed in some way?

No, not really.  There's a single global lock and a race to grab it
when it becomes released by whatever thread was holding it.

> The queue would provide the historical context, and the user dealing
> with queue-entry X would implicitly and transparently switch to
> thread N.

Placing that onus on the user is indeed one solution, but I still hope
we could do better.  There are still problems even with such "manual"
switching: e.g., a background thread will typically run between 2 key
strokes of user's typing, which could be typing at the prompt of
another thread.  So a background prompt may request to be serviced in
the middle of typing a key sequence, and it isn't clear what to do
then.

> >> 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 queue circumvents this: it would allow to present sequentiality (by
> historical context and perhaps by grouping all requests by the operation
> they are involved with) to the user while the execution of threads can
> remain serialized.

Maybe I misunderstood what you proposed, but I thought that a request
gets removed from the queue when its thread finishes its job and
exits.  If this is indeed what you meant, then we would have lost
concurrency.

> Emacs could even assume the possible answers to a prompt and perform the
> actions resulting from the answers in some cases so that when the user
> makes a decision, the result is already available and the one not needed
> can be discarded :)

I don't think this is possible in practice.  We usually ask the user
questions for which only the user knows the answers.