Re: User interaction from multiple threads

[martin rudalics <rudalics@gmx.at>]

 > Tricky at best, IMO.

Porting prompts from one frame's minibuffer window to another is just
as tricky IMO.

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

When switching to a frame I would resume any pending input for the
frame switched to.  This has, a priori, nothing to do with threads.
Input would be processed by the main thread as now.  If a thread was
blocked because it was waiting for input to complete, the main thread
would send a 'thread-signal' to the blocked thread to unblock it as
soon as input is complete.

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

When the thread requests it.  The idea is that a user should not be
pushed to react immediately to the prompt or information provided by
the thread and that none of these get lost in the noise of other
prompts and messages.  Whether such frames are created when the thread
is started or lazily when, for example, the question whether copying a
file should overwrite an existing one with the same name arises, is
left to the thread's writer.  If a thread does not ask for its own
frame, the main thread's mini-window will be used, possibly disrupting
the user's workflow.

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

If the previously-selected frame was that of the main thread, whatever
the main thread currently does.  Though the main thread's mini-window
would never show contents aimed for the mini-window of a separate
thread provided that thread owns a frame.

If the previously-selected frame was owned by a separate thread, it
would show information pertaining to that thread and only to that
thread.

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

You mean when SWITCH-FRAME-OK is set in 'read-key-sequence'?  Maybe
that would require special processing - I haven't looked into it.

martin