Luke Gorrie luke@bluetail.com writes:
For read-string maybe the solution is for Emacs to just send (repl-input <string>) and let Lisp decide what to do with it.
Yes, that's probably good enough.
I also found an exciting new class of dastardly hard bug :-) example:
Make async request Make sync request A Async reply arrives, in continuation: Make sync request B Result of A arrives and is thrown up the stack past B's handler
Can involve a lot of "what happened to A?" head-scratching :-)
With the old protocol we didn't have this problem since it was illegal to make two requests in a row. On the other hand, this wasn't as hard to debug as an `activate'-related bug in the state machine once, and I _think_ it can be solved by the rule "don't make synchronous requests from asynchronous continuations".
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 :-(
Currently the "interesting" bit is figuring out what slime-sync, slime-busy-p, etc are supposed to do, or how to change their callers. This is the chance to make it compatible with out-of-order (e.g. thread-per-request) operation.
Have you any plans for how to debug in the thread-per-request world?
Helmut.