Re: User interaction from multiple threads

[John Shahid]

I had some thoughts recently on this issue.  I see three things being
discussed in this thread:

1. How to implement it.

2. How does this implementation interact with current user input, for
example if the user is in the middle of a key sequence.

3. How does the change affect the APIs and how to request multiple inputs.

4. How to indicate which thread will the input go to.

Regarding the implementation, I'm proposing to use the current
primitives and to implement reading key sequences over IPC/RPC.  The
child thread can request the main thread to display a prompt and return
the value that the user entered.  This is somewhat similar to the idea
of having queues, but I believe has some nice side effects related to
the `2'.

In fact, this IPC/RPC doesn't have to be limited to prompts.  It could
be a general macro that takes any body and return its value, e.g.:

   (on-main-thread
    (read-file-name "source: "))

Since all interactions between the child thread and the main thread go
over IPC, where the main thread act like a server, those prompts will
only be displayed if the main thread was idle and waiting for processes
input.  I believe this answer the second question.

In fact, this email thread made me think about asynchronous processes
and how they interact with the main thread.  A thread is not any
different from an asynchronous process.  An asynchronous process could
(through the process filter) cause user prompt just like threads do.
The exception being, process input plays nice with Emacs' input
handling.  We could make all thread interactions with the display go
over IPC and handled the same way like processes.

Regarding the API, I'm proposing a new lower level `on-main-thread`
macro that can run arbitrary code on the main thread returning the value
of the body.  This can be used to implement multiple prompts, e.g.:

  (on-main-thread
    (let ((src  (read-file-name "source: "))
          (dest (read-file-name "dest: ")))
      `(,src ,dest)))

I also propose that all high level prompt related functions be modified
to do that automatically, e.g.:

   (defun read-file-name (prompt ...)
    (if (not main-thread)
      (on-main-thread (read-file-prompt prompt ...))
     ;; current implementation of read-file-prompt
      ))

This can be used for other display related functions, such as changing
the current buffer or opening a new file, preferring communication with
the main thread as the synchronization mechanism instead of using low
level mutexes.

As to how to indicate which thread the input will go to, I don't
currently have good ideas, other than what have been proposed already in
this email thread.  I also think this is the same problem as an
asynchronous process requesting input.

I apologize for any ignorance regarding the internals of Emacs and how
this proposal might interact with those internals.  I am hoping your
responses will enlighten me and teach me a few things.

Thanks,

-js