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: Sun, 26 Aug 2018 14:52:41 +0200
>> 
>> > I don't see how this would solve the problem, since thread IDs will
>> > always be quite short.
>> 
>> I don´t understand this.  I thought requests for input would be queued
>> in such a way that the users can look at the queue when ever they see
>> fit, and the information in the queue along with the prompts would make
>> it obvious to the users what each request is about.
>> 
>> Wouldn't that be much better than having requests for input and the
>> threads that created them fight over the mini-buffer and interrupt the
>> user once they can hijack the mini-buffer?
>
> You need to catch up with the discussion ;-)

I read it as far as it has come.  Maybe I'm missing something, or am
just misunderstanding.

> 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.  I thought that is not really wanted because it is
so difficult to do?

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?

> Still, when Emacs decides that a certain thread is granted access to
> the minibuffer and can interact with the user, how will the user know
> which of the N threads asks them the question, and for what purpose?

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.

Since threads are not spawned out of nothing for no reason and with no
purpose and nothing they work with --- at least I imagine so --- and
since Emacs creates and manages the threads, it should be able to put
information into the queue along with the request that tells the user
what the request is about.

> The correct answer could well depend on that.  As a trivial example,
> consider 2 threads, one copying files, the other removing files.  How
> do you know whether to confirm or not when the prompt says just "FOO
> (y or n)?"

Simple: Either both threads are in the background because meanwhile, I'm
doing something else, or one of the threads is in the background and the
other one is in the foreground.

The one in the foreground is the one Emacs would direct my input to if I
were to make any.  What that is must not change by itself.  In case
Emacs can not determine where to direct input to (because there are
multiple simultaneous inputs [1]), all requests must be queued.

Threads working in the background must not interrupt me, hence their
requests for input are put onto the queue and do not appear in the
mini-buffer before I attend to them. --- Only threads that execute in
the foreground are allowed to interrupt me (unless I disable that).

In any case I know that requests appearing in the mini-buffer always
refer to what is in the foreground, so in all cases, I know what the
prompt is about[2], unless I can't remember what I was doing in the
foreground.


What you seem to think you must do --- grant an arbitrary thread access
to the mini-buffer --- is what you *must not* do.  And I think you don't
want to do that.  A queue would cover it, that's why I don't understand
what the problem is.

However, a situation like in [1] requires multiple foregrounds.  What
would that bring about?


[1]: I can ssh into a machine running an Emacs server from many remote
     machines as the same user and have a person at each remote machine
     who uses emacsclient with the same server to edit each a different
     file.  How does Emacs figure out which input goes where and what to
     display in which mini-buffer?

[2]: What happens when I press C-g before a prompt appears, or when one
     has appeared?  How do I interrupt a particular operation a thread
     is or multiple threads are performing, possibly in the background,
     or partly in the background, when there is no list of operations I
     can turn to and interrupt the operation from there?  If there is
     such a list, use it to queue the requests related to each
     operation.  (Who says that one operation is done by only one thread
     each?  Does that require a mini-buffer or queue for each operation,
     for each thread or for both?)