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

Luke Gorrie luke at bluetail.com
Sun Jan 25 19:42:01 UTC 2004


Helmut Eller <e9626484 at 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 :-)






More information about the slime-devel mailing list