Helmut Eller e9626484@stud3.tuwien.ac.at writes:
How about this rule: "RPCs should be properly nested"? So a sequence
request A request B reply A reply B
would be illegal. This would be easy to check (with a stack) and is probably a requirement for synchronous RPCs. The downside of this rule is, is that it looks a lot like what we had before :-(
Some comforting observations:
Synchronous RPCs mostly take care of this themselves by blocking Emacs. The only way to make two is if the outer one breaks into a recursive edit, which will probably happen due to needing to be debugged, where it's probably safe to make inner synchronous RPCs.
Synchronous commands always have to be able to cope with abort because of C-g. So if we just abort them when the stack returns out of order, nothing really bad should happen, the command just gets aborted.
I'm guessing we can program around the problems pretty easily. But you probably noticed the ol' PowerPoint trick of using a bullet-list for an argument that I can't express convincingly in prose :-)
Allowing "pipelining" multiple requests to Lisp and accepting results out-of-order would open a lot of flexibility for threading. For example with thread-per-request you could do `C-c C-k' and still use M-. and so on while you wait for the compilation. I *totally* missed that idea in my previous multithreading attempts but now I suspect it's the most important bit.
Have you any plans for how to debug in the thread-per-request world?
Some ideas at least. We extend the (:DEBUG ..) message with a THREAD-ID so that we can give threads their own *sldb* buffers. We also extend RPCs from Emacs to include a THREAD-ID so that the *sldb* buffers can talk to the right thread (and so the REPL can always talk to the same thread, and maybe commands in buffers could use T to mean "in a new thread" perhaps).
I think that's actually enough for the machinery, since now the debugger state only exists in Lisp stacks (per thread) and the *sldb* buffer-locals (per thread). We could then build a user interface on top that decides when debug buffers should actually be popped up etc.
Or something :-)