Re: save-excursion and multi-thread?

[Eli Zaretskii]

> From: Qiantan Hong <qhong@mit.edu>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 27 Sep 2021 05:00:01 +0000
> 
> I’m experimenting remote commands in my collaborative environment package.
> Normally the client just send a message describing the command invocation,
> and the server execute it inside process filter (which runs inside main 
> thread).
> Server has to wrap save-mark-and-excursion around it, and move point and mark
> to those of the client. Then everything works as intended, if the command run 
> itself
> without interruption and return in a short time.
> 
> Unless the command calls interactive functions like READ-FROM-MINIBUFFER.
> Now we need to do a “recursive” remote procedure call, by overriding such 
> interactive function
> to send a message back to client and wait for response. 
> Now whatever thread that runs such remote command
> can’t do anything but waiting (unless we transform the code of such remote 
> command
> to async, or CPS, style, but one of my primary design goal is to be able to 
> let
> “stock” emacs code just work). It’s therefore infeasible to immediately run 
> such
> remote command in process filter as once it calls interactive function, it 
> blocks
> main thread and makes server unresponsive.
> I therefore have to spawn a new thread for such remote command.

Why do you need to start a new thread? why not have the filter
function send the message to the client, and arrange for waiting for
the response to that message via the same filter-function method
(perhaps by changing the filter-function temporarily to some other
function)?

IOW, it sounds to me like you need to suspend the execution of the
command until the client answers the question, and you already have
the machinery to handle bidirectional communications between the
client and the server, so just reuse it for asking a question and
receiving the response, before you perform the command.  Am I missing
something?

> I guess indirect-buffer will make it sort of work, although looks like it 
> copies lots of stuff
> and might be costly?

It's definitely not clean enough, I agree.