Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Date: Tue, 14 Aug 2018 12:42:04 -0400
> 
> #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.

"Waiting for input" means waiting for user to type something.  That is
normal Emacs situation when the user does nothing, so unconditionally
sending input to the main thread and letting the other thread wait
would mean that other thread might wait indefinitely.

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

Do we need to tell the user the other thread wants to prompt?

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

Not necessarily, it could be added to the corresponding primitives.

Thanks.