[slime-devel] Re: eval-string bug?

[Helmut Eller]

Luke Gorrie <luke at 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.