Re: User interaction from multiple threads

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

Michael Welsh Duggan <mwd@md5i.com> writes:

Hi,

>> Use case #1:
>>
>>   . The main thread is waiting for user input.  The user didn't yet
>>     type anything
>>   . A non-main thread runs Lisp that prompts the user for some input
>>
>>   In this case, we probably want the following input to go to the
>>   prompting thread, right?  But it might also be the case that the
>>   user actually wants the input to go to the main thread, e.g. to
>>   perform some unrelated command.  Should we allow that?  If yes, how
>>   should Emacs know which thread should receive what the user types?
>>
>> Use case #2:
>>
>>   Same as the previous, but now the user is in the middle of typing a
>>   key sequence, when the non-main thread prompts.  For example,
>>   suppose the user has typed "C-x".
>>
>>   What do we want to happen now?  Do we "preempt" the main thread and
>>   let the following input to go to the prompting thread?  Or do we let
>>   the prompting thread wait until the main thread reads a full key
>>   sequence and runs the command bound to it?  If the former, what to
>>   do with the partial key sequence ("C-x") that the user typed?  If
>>   the latter, how do we indicate to the user that there is a prompt
>>   from another thread?
>>
>> Use case #3:
>>
>>   Similar, but now 2 or more non-main threads prompt the user, one
>>   after the other, in quick succession.  What should happen now, and
>>   how will the user know there are multiple prompts?
>
> #1 If "waiting for input" means in read-from-minibuffer or something
>    similar, I believe that input should go to the the thread.  The other
>    thread will have to wait.  If "waiting for input" means idle, it
>    should go the the other thread.

I agree. If there is already a prompt in the minibuffer, the input shall
be related to that prompt. If the user wants to do something else (enter
a command for the main thread), she shall cancel the existing prompt with C-g.

Maybe we shall mark the requesting thread for user input somehow, for
example by a modeline indicator with related help-echo.

> #2 You should neveer break a key sequence.  We do not preempt the main
>    thread.  The other thread will have to wait.

I agree. If a user has started typing input, no other thread shall
interrupt this by showing its own prompt, and reading own input. The
other thread has to wait.

> #3 Each thread should get to ask its question in turn, with its own
>    prompt.  Other threads will block until that question is answered.
>    The user will know there are multiple prompts because after they
>    answer one, they get asked another.

Agreed. The prompts must be designed such a way, that a user knows what
she is responding to. She cannot expect a defined order of the prompts.

For example, when answering a question about a file, the prompt shall
always contain the file name the question is related to.

> User input has to have a beginning and an end.  The simple cases are
> easy: a single full key sequence or a read-from-minibuffer call.  But in
> many cases an application has a series of prompts to be asked and
> answered in succession.  So these inputs need to be able to be grouped
> somehow along with their prompts.  Then, once a group is executing, any
> other input-related groups raised by other threads have to wait for the
> current input group to finish.  Then they cay be served in FIFO or
> random order.
>
> The easiest was I can think of grouping sets of inputs is as some form
> of critical section, maybe implemented by mutexes.  This would be
> simplified for the programmer with a convenience wrapper, something like
> (with-input-group BODY) or some such.

Would be useful for new and adapted code.

> Unfortunately, this proposal suffers in that it would have to be
> retroactively added to existing code.  So for existing code, some form
> of heuristic will have to be used instead.  The only one that comes to
> mind is this: Once an input sequence begins, input is locked to that
> thread until that thread ends, explicitly ends input operations (with
> some new directive), or (in the case of the main thread) returns to the
> command loop.  Now, I can see problems with that.  What happens when a
> thread prompts for input and then sits and blocks waiting for something
> else?  Unless we can categorize certain blocking operations as ones that
> will release the input mutex.

I don't agree with this heuristic. Even if we don't run into deadlocks,
one thread with a simple y-or-n-p question would block all other threads
until it finishes, which could take time. We must accept that for not
adapted code user input is requested from different threads, in random
order. The only guarantee is, that user input for the same thread is in
predefined order.

Over the time, code will be adapted for threads to use the grouping
feature as proposed above.

> Sorry, this was very much stream-of-thought.  

Same here.

Best regards, Michael.