Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: psainty@orcon.net.nz, hw@adminart.net, gazally@runbox.com,
> 	emacs-devel-bounces+psainty=orcon.net.nz@gnu.org,
> 	emacs-devel@gnu.org
> Date: Fri, 24 Aug 2018 20:20:48 -0400
> 
>   > 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.
> 
> This might be ok if the thread's further prompts arrive in short
> succession.  But what if it runs for 5 minutes and then asks
> for input?  Should other threads be blocked for those 5 minutes?

If that thread runs (i.e. does some Lisp and never calls
wait_reading_process_output), all the other threads will be blocked
anyway, because the global lock is taken by the running thread.

> I think the point of multiple threads is to avoid that.

To some degree.

> Would a thread explicitly seize the terminal and hold it and
> later release it?  Or would asking for input hold the terminal

My conclusion from the discussion is that when a thread asks for
input, it might be too late, because the prompt was already issued.
But maybe we will be able to do something in the redisplay code to
prevent the prompt from showing, in which case the terminal could
indeed be seized when asking for input.  If not, it will have to be
seized just before issuing the prompt.

> until the thread exits?

Not until it exits, until it no longer needs to interact with the
user, for the current transaction (whatever that means).

>   > If that's the first prompt in a series of prompts, we should fix the
>   > prompt to tell what password does it ask for.
> 
> I don't think that is practical to do in all cases.  In some, yes.
> But what if two threads run the same function?  The prompt could be
> identical.

I'd need a practical example to discuss this in more detail.
Theoretically, you are right, but in practice it could be that the
responses are identical (in which case it doesn't matter what thread
asks the question).  Or the prompts will have to be upgraded to speak
for themselves, for example:

  Host for accessing file FOO:
  Password for accessing file FOO:

etc.

>   > 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?
> 
> If we tell people, "Give your thread a meaningful name if it is going
> to ask for input", and we explain why, they will mostly do it.
> When they don't, we can fix it.

I'm saying that fixing the prompt itself is a better alternative,
because we will always give the prompt more screen estate than to the
thread ID.  Also, the thread ID is fixed for each thread, whereas we
could add different text to each prompt to make each one more
self-describing.

But in general, I see no significant difference between these two
alternatives, because they both add some text to the prompt.