Re: User interaction from multiple threads

[Michael Welsh Duggan <mwd@md5i.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> For background, see bugs #25214 and #32426.  Some additional
> discussion was here:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2016-12/msg00607.html
>
> I'm trying to revive those past discussion, because we now have a
> serious and useful application that bumped into these problems, where
> formerly we only had theoretical discussions and toy programs.
>
> After thinking some more about this, I think we should first pay
> attention to conceptual issues related to this, before we start
> talking about implementation.  The conceptual problem I see here is
> the UX when more than one thread needs to interact with the user.
>
> For the following description, recall that normally only the main
> thread will wait on the keyboard descriptor (why that happens was
> explained in bug#25214).
>
> 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?
>
> Thoughts?

Here are nmy answers to
your three use cases:

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

#2 You should neveer break a key sequence.  We do not preempt the main
   thread.  The other thread will have 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.

Without trying to figure out how it would be implemented, I think I'd
want the following:

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.

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.

Sorry, this was very much stream-of-thought.  
-- 
Michael Welsh Duggan
(md5i@md5i.com)