[slime-devel] Re: `slime-repl-abort-read' bug?

[Taylor R Campbell]

   Date: Sat, 25 Nov 2006 00:38:20 +0100
   From: Helmut Eller <heller at common-lisp.net>

   Yes, it's a bug.  But one could argue, that the current implementation
   satisfies LIFO unless two threads read simultaneously from the same
   stream [and that the stream should synchronize concurrent reads].

OK, that makes sense; I was just not thinking straight when I read my
own implementation of the Lisp side of REPL reading earlier.

   When should we switch between normal mode and read mode?  I think it
   would be quite intuitive, if we switch to read mode after we sent the
   expression to the REPL thread and switch back to normal mode when we
   receive the result.

   With this design, we don't need to worry much about interrupts,
   concurrent reads can be handled by buffer thread, and the
   implementation the READ-CHAR-NO-HANG becomes straightforward.

I'm a little confused about this.  How would threads other than the
REPL thread request input from the user in this model (between REPL
evaluations), and why is READ-CHAR-NO-HANG any different?  It seems
that, for any code that is not the buffer thread, the action of
reading input is no different: you send, to some input source, a
request for new input.  The only difference is what the input source
is -- in the current model, it's Emacs, whereas in this new model,
it's the buffer thread.