Re: User interaction from multiple threads

[martin rudalics]

> You might be thinking about some mechanism we don't have, and didn't
> discuss yet, because currently windows and buffers are not "owned" by
> threads.

That's what I meant in my first post of this thread with "If we make a
rule that each thread owns a frame with a minibuffer,".

> Any thread can modify any buffer and call any functions that
> manipulate windows.

A frame owned by a thread can be manipulated only by that thread.
Some mechanism may be needed to delete such frames when a thread dies
and is no more able to do that itself.

>> The non-main thread would prompt in another frame and the user can
>> choose whether to continue with her input or have a look at the
>> prompting frame and answer that prompt.
>
> 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.  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.  And reading a key sequence through the
echo area is IIUC synchronous anyway so a user cannot practically
switch frames during that.

martin