[Top][All Lists]

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

Re: User interaction from multiple threads

From: John Shahid
Subject: Re: User interaction from multiple threads
Date: Thu, 30 Aug 2018 12:08:32 -0400
User-agent: mu4e 1.1.0; emacs 27.0.50

Eli Zaretskii <address@hidden> writes:

>> From: John Shahid <address@hidden>
>> Cc: Eli Zaretskii <address@hidden>, Gemini Lasswell <address@hidden>, 
>> address@hidden
>> Date: Wed, 29 Aug 2018 22:34:02 -0400
>> > The notion of user interaction all happening on the main thread was
>> > proposed earlier, and it was pointed out that it's very difficult to
>> > do that, because the user interaction may involve arbitrary data which
>> > is local to the originating thread.
>> I thought closures would solve such a problem by encapsulating the
>> context.  I imagine the main thread receiving forms from other threads
>> evaluating them and returning the results back to the thread which
>> becomes the value of the `(on-main-thread ...)`.  What did I miss ?
> I'm afraid there's too much to encapsulate.  E.g., every buffer-local
> variable in every buffer to be used by the thread will need to be
> encapsulated; and how will the main thread know in advance all that?

Why do we need buffer local variables for all the buffers ? Isn't the
current buffer during the prompt the only relevant buffer. I was
thinking that the `(on-main-thread ...)` macro (or whatever it ends up
being called) can expand to something like the following:

      (let ((buf (current-buffer)))
        (lambda ()
          (with-current-buffer buf

> And I think your mental model of how threads work in Emacs is
> inaccurate: the main thread doesn't dispatch the other threads, in the
> sense of controlling them and interacting with them.

I know, I am proposing to change that but not in a very intrusive way.
My idea, is that each thread is started with a pipe which is used to
interact with the main thread when it needs to prompt the user.  The
child thread write the lambda that needs to run on the main thread then
wait for main thread response using `accept-process-output'.  The main
thread handles the request in the process filter displaying the prompt
and writing the result back to the pipe. Since the child and main thread
are sharing the same memory, the communication can simply be the symbol
name that holds the closure and the response, respectively.

Hope this clarifies my idea. Happy to hear your thoughts.

reply via email to

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