Re: User interaction from multiple threads

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden,
>       address@hidden,
>       address@hidden
> Date: Thu, 23 Aug 2018 22:00:03 -0400
> 
>   > > With multiple threads asynchonously requesting input, I have a feeling
>   > > that users will get confused in complicated situations as a result of
>   > > not knowing which thread the input is for.
> 
>   > Yes, and I think we all agreed that some sort of serialization is
>   > needed.
> 
> We agree about the serialization, but the issue I am not talking about
> now is different.  I am talking about managing the various input
> requests -- choosing the order of the requests, and identifying which
> request is being made now and on behalf of which activity.

The idea expressed by several people is that once you start
interacting with some thread's prompt, the other threads are locked
out of interaction, until the interacting thread is done with the
series of prompts that allow it to go on with its business.

>   > Why is that important?  Wouldn't the prompt itself be informative
>   > enough?
> 
> We can hardly assume that the prompt shows which activity is asking
> for the input.  What if two different threads ask for a Password?
> The prompt might say, "Password: ".  Which password should it be?

If that's the first prompt in a series of prompts, we should fix the
prompt to tell what password does it ask for.  But it is okay, I
think, to have a series of prompts from a single thread which go like
this:

  Host to logon:
  Password:
  Initial directory:

As long as the user knows this is a coherent series of prompts from
the same thread, she will have no difficulty filling in the blanks,
exactly like she does that now.

>   >   And how (in what terms) would you suggest to indicate the
>   > thread ID in this case?
> 
> I don't know enough about the thread feature to figure that out.
> Perhaps based on the thread's top-level function call?
> Do threads have names?

They do, but the name is optional.  If the Lisp program that starts a
thread doesn't provide a name, Emacs will identify it as something
like #<thread 0x01a2d468>, which is not helpful in the situations we
are discussing.

And even if we do require each thread to have a name, what guarantees
do we have that the name will be more informative than the prompts
about which you were worried?