Re: User interaction from multiple threads

[Phil Sainty <psainty@orcon.net.nz>]

On 2018-08-20 11:08, Gemini Lasswell wrote:
> Perhaps the way to accomplish this is to always read keyboard input in
> the main thread.  So when read-from-minibuffer, for example, is called
> from a non-main thread, it would put the prompt on a queue for the main
> thread to process, and then block until the response is ready.

>> 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?
> 
> The first thread should get to show its prompt and wait for a response,
> and then show followup prompts if it can present them immediately after
> the first is answered.  Other threads will block until the threads 
> ahead
> of them are done prompting.


I'm pondering the details of that "and then show followup prompts if it
can present them immediately" part...

Say a thread has pushed its first prompt onto a queue, and then blocked.
At this point there is no knowledge of whether or not that thread may
have follow-up prompts to issue once it is unblocked.

In the meantime, additional threads may also push prompts onto the 
queue.

Once it's safe for the user to be prompted, the first thread's prompt is
processed in the main thread, and the result is established and passed
back to the calling thread, which then resumes processing.

So long as that thread doesn't voluntarily yield, it would be able to
generate a follow-up prompt before any of the other pending prompts from
other threads had a chance to be processed.  However, it's also going to
need to jump the queue.

If the main thread is managing the queue of pending prompts, is it
sufficient for the main thread to track the single most-recent thread
with which the user interacted, and to always prioritise queue items
from that thread over any other queue items?


-Phil