Re: User interaction from multiple threads

[Gemini Lasswell <gazally@runbox.com>]

Phil Sainty <psainty@orcon.net.nz> writes:

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

That's what I was thinking, but you bring up a good question to which I
don't know the answer.  After the main thread processes the first
thread's prompt and stores the user's response, it needs to yield so the
first thread can resume execution.  Is it guaranteed that the thread
scheduler will allow all other ready threads a turn to execute during
the main thread's thread-yield?

If not, maybe a good-enough-most-of-the-time solution would be for the
main thread to do a sleep-for for an amount of time that won't bother
the user, like 0.1s, and if the most-recent thread hasn't added a prompt
to the queue by then, then go on to the next thread's prompt.