Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 30 Aug 2018 01:21:51 +0100
> From: Uday Reddy <usr.vm.rocks@gmail.com>
> 
> >   . 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
> 
> I guess it is obvious that the non-main thread shouldn't interfere until the
> main thread's interaction is completed.

When the main thread is waiting for input, the interaction didn't yet
start, so I don't think "until completed" is well-defined in this
case.  This use case is about the main thread being idle waiting for
the user to type something in order _to_begin_ the interaction.

> >   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?
> 
> I don't see "quick succession" as being an issue. The user is going to take
> his/her own time to answer. So, it can't happen too quickly.

"Quick succession" describes what the background threads do, not how
the user will react.  It is quite possible for several threads to want
to interact with the user almost simultaneously.

> Now suppose multiple related prompts come from separate calls in the main
> thread. Then there must be a way to tie all those calls together, in the
> manner of a database transaction, and another thread be allowed to prompt
> only after the transaction completes.

Yes, we arrived to the same conclusion, more or less.

The problem that remains is how to mange the beginning of some
interaction, how to tell the main thread "to get lost" for a while,
and how to control which thread gets the interaction permission when
the first one is done with its.

Thanks.