Re: User interaction from multiple threads

[Eli Zaretskii]

> Date: Fri, 17 Aug 2018 10:34:54 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  > That just postpones the question, because now we need to have some
>  > infrastructure in place that "knows" which frame's input goes to what
>  > thread.
> 
> To the thread that owns that frame.
> 
>  > And it leaves intact the fundamental implementation-level
>  > difficulty, about which I will write shortly: namely, that we have
>  > only one input "pipeline", which needs to somehow be enhanced to
>  > multiplex between several threads.  The fact that the prompt is shown
>  > in another frame doesn't resolve the difficulty with channeling the
>  > input in response to that prompt, especially when multiple different
>  > prompts are being displayed at the same time.
> 
> There would still be only one input "pipeline" at any time, namely
> that of the selected frame.  Just that switching frames now would call
> for "saving" the input pipeline of the frame switched from and
> "restoring" any input pipeline of the frame switched to.

Tricky at best, IMO.  Frame switch is just another input event.  I
guess you are thinking about adding calls to thread-yield into input
processing code?

Also, does it mean that every call to make-thread will now pop up a
new frame?

> IIUC we are able to save and restore an input pipeline when we enter
> and leave a recursive minibuffer so the mechanism for doing such
> switches seems to exist for minibuffer reading.

What will appear in the minibuffer window of the previously-selected
frame while we interact with another thread's frame?

> And reading a key sequence through the echo area is IIUC synchronous
> anyway so a user cannot practically switch frames during that.

Are you sure they cannot switch frames in the middle of reading from
the minibuffer?