* Taylor R Campbell [2006-11-24 20:55+0100] writes:
`slim-repl-abort-read' ignores its two arguments and just pops `slime-read-string-threads' and `slime-read-string-tags'. Is the Lisp system really assumed to request and to abort REPL reads in a LIFO manner, or is this a bug?
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].
Or is my understanding of the way SLIME's REPL read mode works bogus?
Well, the REPL read mode is more or less broken by design. Currently, the Lisp side essentially turns a read operation on a stream into an RPC. Emacs will then switch the REPL buffer into read mode, switch back to normal mode after the user has entered some text, and return the text to Lisp. Obviously, the situation becomes horribly complicated if the RPC gets interrupted.
A simpler approach would be this: like now the REPL buffer can be in "normal mode" and in "read mode". In normal mode the REPL buffer communicates only with the REPL thread (i.e. sends expressions, waits, and prints result). In read mode, we only talk to a "buffer thread" on the Lisp side. The buffer thread basically buffers the input from Emacs. If other threads want to read input from Emacs, they ask the buffer thread (instead of talking to Emacs).
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.
The only thing left is to implement this idea in a Lisp without threads.
Helmut.