[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: User interaction from multiple threads
From: |
Michael Albinus |
Subject: |
Re: User interaction from multiple threads |
Date: |
Fri, 24 Aug 2018 13:44:39 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Eli Zaretskii <address@hidden> 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:address@hidden:/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.
- Re: User interaction from multiple threads, (continued)
- Re: User interaction from multiple threads, Richard Stallman, 2018/08/23
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/23
- Re: User interaction from multiple threads, Phil Sainty, 2018/08/23
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/24
- Re: User interaction from multiple threads, Phil Sainty, 2018/08/24
- Re: User interaction from multiple threads, Richard Stallman, 2018/08/24
- Re: User interaction from multiple threads, Richard Stallman, 2018/08/24
- Re: User interaction from multiple threads, Richard Stallman, 2018/08/23
- Re: User interaction from multiple threads, Elias Mårtenson, 2018/08/23
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/24
- Re: User interaction from multiple threads,
Michael Albinus <=
- Re: User interaction from multiple threads, Elias Mårtenson, 2018/08/24
- Re: User interaction from multiple threads, Michael Albinus, 2018/08/25
- Re: User interaction from multiple threads, Elias Mårtenson, 2018/08/27
- Re: User interaction from multiple threads, Richard Stallman, 2018/08/24
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/25
- Re: User interaction from multiple threads, Phil Sainty, 2018/08/25
- Re: User interaction from multiple threads, Richard Stallman, 2018/08/25
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/25
- Re: User interaction from multiple threads, hw, 2018/08/26
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/26