Re: save-excursion and multi-thread?

[Qiantan Hong <qhong@mit.edu>]

> 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?
Exactly, however I want the machinery to work for ordinary Emacs “stock” 
commands with minimal effort.

Suppose we opt to rewrite any Emacs command that would be remote-called,
then of course it’s easy to rewrite them so that they immediately return
when they originally READ-FROM-MINIBUFFER while pushing the rest
of the original command as a continuation on some queue 
(this is in fact just a CPS transform). 
The filter function will then execute continuations on the queue upon
receiving response.

We still need to deal with restoring point/mark/etc when switching continuation
(i.e. we need to save state when the command “immediately return” and
restore state when we run the continuation on the queue), but it’s well in our
control and doable.

However I want to use original commands without modification if possible.

My current trick is to run the whole command in new thread, and
override READ-FROM-MINIBUFFER using advice.
It’s conceptually very similar to the above CPS transform solution
(thread-yield is basically (call/cc (lambda (k) (push k continuation-queue))))
However there’s complication that thread-yield might happen at points
out of our control. We thus cannot rely on manually save/restore state
and have to put our hope on some primitive
(just like in a system that switch thread at well defined point one
can implement thread-local dynamic binding in the library, but
has to rely on primitive provided by runtime if there’s preemptive switching
or real parallelism).
Unfortunately such primitive doesn’t seem to exist for point and mark.

Another trick I could think of is to not start a new thread, but
override READ-FROM-MINIBUFFER such that it starts a recursive edit.
Therefore the unfinished state of the command is still on the stack and
we resume it by EXIT-RECURSIVE-EDIT upon receiving response.
It sounds like more madness… and it won’t quite work if the order of receiving
response is different from the order of sending questions.