Re: User interaction from multiple threads

[hw <hw@adminart.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Users still require sequentiality to be able to deal with them.

>> 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.

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.

>> 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.

Aren't the threads already managed in some way?  The queue would provide
the historical context, and the user dealing with queue-entry X would
implicitly and transparently switch to thread N.

>> 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.

The disadvantage is that when there goes something wrong with a sequence
(bad example: visiting a file before being prompted for a file name),
the user may have a hard to time to notice that there is something
wrong (unless the grouping by operation makes the queue entry appear in
the wrong historical context maybe).

> 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.

All threads can run in any arbitrary order as long as they queue their
requests.

The alternative is interrupting the users with prompts out of sequence
so they do not know what Emacs wants, prompts serialized or not.

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 :)