Re: User interaction from multiple threads

[hw]

Eli Zaretskii <address@hidden> writes:

>> From: hw <address@hidden>
>> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
>> address@hidden
>> 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.

I think Emacs might need at least some help from the user to make the
right decision.

Imagine serializing requests and presenting them to users with the right
amount of sequentiality and historical context was already solved.  What
is Emacs supposed to do with requests after I start using it for
programming and tell it that I am in do-not-disturb-mode?

That mode means that I do not want to be disturbed by any prompt which
is not directly related to what I'm currently doing, i. e. it's ok for
Emacs to ask me for a file name right away when I press C-x C-f.  It is
definitely not ok to prompt me "FOO (y or n)" because Emacs is still
copying or deleting files and wants to know something.  I'd look into
the progress of that some time later, or the next day maybe.

It is also not ok for gnus to change the size of the mini-buffer or to
ask me for a password when it automatically checks for new mail every
now and then.

Since there is no such thing as "a foreground", Emacs has no idea what
I'm doing and no way to decide which requests it may allow to reach me
and which ones not.  It might help if I could qualify them so I can tell
Emacs which classes of requests to allow and which ones not.

Or it needs to queue them all.

> My point above was that having several minibuffers doesn't solve the
> basic problem,

yes, I agree

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

If Emacs shall be allowed to control the users in such a manner, it
should always forward those requests the users want to currently deal
with and withhold the ones they do not want to see :)

How does Emacs figure out what a user currently wants to deal with?  The
user could help Emacs by going into the do-not-disturb-mode and giving
it an adjustment period of, say, 10 seconds.  During these 10 seconds,
the user does nothing, and Emacs does not create any new threads and
does not forward any requests.

After that, Emacs forwards only those requests that have come up after
the adjustment period and have been created by threads that were created
after the adjustment period and, if they were created by other threads,
the threads creating them must not have been created before the
beginning of the adjustment period.

This is probably a retarded idea which sucks, but it is a kind of way,
time based, to figure out what the user is currently doing.  But it
would allow Emacs to prompt me right away for a file name when I want to
visit one, which is what I would want.

While the user is not in do-not-disturb-mode, it doesn't matter which
prompt is forwarded first.  It could be the oldest one, a random one or
the newest one, maybe depending on which the user prefers.

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

How is being decided for how long the most a thread can stall the
others?  What information is available when a thread is created?

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

hm

Yeah it would suck if was prompted for FOO instead of for a file name
when I wanted to visit a file.

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

A request would be removed from the queue when it has been served
(answered) by the user.  How would a thread that needs to wait for the
answer finish its job before it has been given the very answer it needs
to finish?

There wouldn't be much point in allowing threads that need to wait for
an answer to stall others.  The others could still run.

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

While (query-replace) is waiting for the user to answer its prompt,
Emacs could anticipate the possibility that the user is going to perform
all the possible replacements (after verifying only a few) and create a
version of the buffer in which all replacements have been performed. Now
when the user actually does what Emacs anticipated, it switches the
buffers so the user doesn't need to wait for the replacements to be
performed (assuming that would be faster than doing the replacements,
for the sake of this example).