bug#25214: 26.0.50; Interacting with user from threads other than the primary

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Can you describe what exactly would you like someone else to
> implement?  IOW, what minimal change will allow you to continue your
> work in this direction?

I don't know whether I could do this exactly. But the problem in this
bug report is, that we cannot dedicate keyboard input to a non-main
thread. Usually this is not a problem, I believe that plain editing
shall always happen in the main thread. But sometimes we have the need
to communicate with the user from a non-main thread.

This is a scenario like echoing the prompt "Do you want to delete file
foo?", and the user will type the answer. All this must happen in the
current thread, and also related buffers must be kept (often there is a
help buffer for possible answers).

The point is, that this happens while a pselect is running, which has
dedicated keyboard file descriptors to the main thread already. This
pselect must finish (likely by waiting for the timeout), keyboard
related file descriptors must be rearranged, and a new pselect must be
started which reads the input inside the current thread.

When finished, file descriptors must be rearranged to the main
thread. All of this must happen, while the current thread blocks the
main thread.

Likely, this cannot be done automatically, so we need a function
`set-keyboard-thread' (similar to `set-process-thread'), which is called
for scenarios as described. And since the keyboard must be reset to the
main thread, maybe a macro like this is needed:

(defun with-blocked-keyboard (&rest body)
  `(block-other-threads ;; maybe via a mutex??
     (set-keyboard-thread (current-thread))
     ,@body
     (set-keyboard-thread main-thread)))

It is the fiddling with pselect and the keyboard file descriptors, which
I'm not able to handle.

> Thanks.

Best regards, Michael.