[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User interaction from multiple threads

From: Phil Sainty
Subject: Re: User interaction from multiple threads
Date: Tue, 21 Aug 2018 10:38:59 +1200
User-agent: Orcon Webmail

On 2018-08-21 05:03, Eli Zaretskii wrote:
Remember: the prompting thread called some function, like
read-file-name, and that function has its own ideas for how to
interact with the user -- how will the prompting thread tell the
main thread all those details?  Some of the details reference
variables that are local to the prompting thread's current-buffer,
about which the main thread knows nothing.  The main thread will
need to thoroughly "emulate" the prompting thread to DTRT here.

I was wondering about this too, and concluded that the main thread
probably can't read the input (for the reasons you've outlined), but
that the more general approach of the main thread *coordinating* the
reading of input based on information from the other threads might
still be viable and useful.

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.

At that point, as in the prior suggestion, it blocks until the main
thread decides that the user-interaction is safe.  But instead of the
main thread reading the input itself and then passing control (and the
result) back, it simply passes control back to the prompting thread --
which will read the input for itself and continue processing.

I think that's the same outcome as the prior suggestion, but without
the magic of one thread knowing all about another thread.

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.  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.  And my thought about
queue-jumping procedures would still work the same as before, so that
a single thread could read a series of user inputs without other
threads interjecting with their own reads.


p.s. I'm afraid I've not been following the whole discussion, so
apologies if I'm just covering old ground here, or ignoring other
critical elements.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]