Re: User interaction from multiple threads

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 21 Aug 2018 10:38:59 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Gemini Lasswell <gazally@runbox.com>, emacs-devel@gnu.org, Emacs-devel
>  <emacs-devel-bounces+psainty=orcon.net.nz@gnu.org>
> 
> Instead of the prompting thread pushing its prompt into a queue for
> the main thread to somehow execute, the prompting thread could instead
> simply push onto a queue a *notification* that it needs to perform
> some user interaction.

This must happen before the prompt is displayed, so it means we will
need to identify all the functions used for prompting (or channel them
all into a single low-level function), and do this enqueuing there.

> The queue is then essentially the list of threads which are awaiting
> the opportunity to perform user-interaction.  When a non-main thread
> attempts to read input from the user, it is automatically blocked and
> pushed onto the queue.

Not "read input", but show a prompt, right?  We don't want to show a
prompt to which the user cannot respond, right?

> Any thread which is blocked on this account is only allowed to
> resume when Emacs decides that it is safe for user interaction for a
> non-main thread to occur.

Who is "Emacs" in this sentence? the main thread?  For that to
happen, the main thread needs to resume, and for that, some other
thread should awaken it.

So we need some additional synchronization facilities for this scheme
to work, and we also need a way to stop the normal "scheduling", so
that we could make sure only the thread that is currently interacting
with the user can run, even if it calls an API that normally will
allow rescheduling.