Re: User interaction from multiple threads

[Uday Reddy <usr.vm.rocks@gmail.com>]

Sorry for getting into this discussion a bit late:

> 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

I guess it is obvious that the non-main thread shouldn't interfere until the
main thread's interaction is completed.

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

Again, the non-main thread shouldn't interfere.

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

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.

But the problem in my mind is that the main thread could be prompting for
multiple things, e.g., think of M-x ediff-files. The non-main thread
shouldn't interference until all of those are completed.

Probably in many cases, the mutliple prompts all come from the same
(interactive...) form, in which case all of them need to complete before
another thread can start prompting.

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.

I think the database transaction model is a good one to follow here.

Cheers,
Uday