Re: save-excursion and multi-thread?

[Qiantan Hong]

> Moving point behind the back of the main thread is a bad idea, you
> will expose the movement to the user when redisplay hits.
> 
>>>> Does that convince you?
>>> 
>>> Convince me to do what? redesign and reimplement Lisp threads in
>>> Emacs with very different design goals?
>> Not doing anything, let’s figure out what’s correct first.
> 
> I don't see anything that needs fixing here.  Once again, the basic
> design was to allow other threads work on other buffers, which is why
> each thread has its own current buffer.  This is how this stuff was
> designed, so yes, we are talking about design goals.
> 
>> I also don’t think a redesign is necessary, we just need to
>> restore point state during thread switching, but I haven’t look at detail 
>> yet.
> 
> In interactive use, moving point in a thread that doesn't perform
> redisplay will surprise the user, and I don't see how you could avoid
> that.  So I don't think this idea will fly.
I see, thanks for the clarification.

> Would you mind explaining in more detail what you want to accomplish?
> Perhaps there are better ways of doing that that are already
> supported, or could be supported with cleaner changes.  I'm not going
> to agree to any changes that would make it easier for 2 threads to
> work on the same buffer, that way lies madness: buffer changes use a
> lot of global machinery behind the scenes.
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.
And I do what used to work — wrap the actual command call with 
save-mark-and-excursion,
setup mark and point and according to client, but this time in a separate 
thread.
Boom, it doesn’t work at all! For the reason discussed in previous messages.

I guess indirect-buffer will make it sort of work, although looks like it 
copies lots of stuff
and might be costly? I definitely want remote command call to be as fast as 
possible
because it’s a foundational facility for building lots of other stuff...