Re: User interaction from multiple threads

[Michael Albinus <michael.albinus@gmx.de>]

Eli Zaretskii <eliz@gnu.org> writes:

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

Yes. The simplest locking mechanism I could imagine is a mutex locking
such interactions. This must be used for every
echo-a-prompt-and-read-the-answer interaction by default (we shall
determine all low-level cases). And it shall be a predefined, documented
mutex, like `interaction-mutex'.

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

If this series of prompts happen in a thread, the implementation of this
prompt series shall protect them by the same `interaction-mutex'. It
doesn't hurt for the prompts themselves, because their locking with
`interaction-mutex' belongs to the same thread, and mutexes are
recursive (meaning that a thread can re-acquire a mutex it owns any
number of times). All other threads are locked when they try to acquire
the `interaction-mutex'.

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

Since there are no rules for thread names, I use the visiting function
name and the name of the visited file in the feature/tramp-thread-safe
branch. Thread names are here like #<thread find-file
/ssh:user@host:/usr/local/src/emacs/CONTRIBUTE>, which could be used
hardly for indication with limited space in the echo area. The only
place it could be used is a tooltip of the prompt, I believe.

Best regards, Michael.