Re: User interaction from multiple threads

[Eli Zaretskii]

> Date: Sat, 18 Aug 2018 10:31:06 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  > Tricky at best, IMO.
> 
> Porting prompts from one frame's minibuffer window to another is just
> as tricky IMO.

Except that it doesn't involve threads.

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

Unless I'm misunderstanding you, this has everything to do with
threads, because the input from the newly-selected frame should be
processed by a different thread than the one which was "current"
before the switch.

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

thread-signal signals an error (like 'signal' does), so the signaled
thread will exit as soon as it resumes running, which is not what you
want.  That's why I mentioned thread-yield.

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

What does "left to the thread's writer" mean in this context?  Given
the low-level details involved, which cannot be done from Lisp, how
can we leave this to the application?  I'm probably missing something.

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

I don't think this can fly with how redisplay works, can it?