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

[Helmut Eller]

* Taylor R Campbell [2006-11-25 01:48+0100] writes:

> 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?

READ-CHAR-NO-HANG is different because it must return immediately, but
a RPC can block indefinitely.  E.g. a loop like:

 (loop repeat 20 until (read-char-no-hang) do (sleep 1))

should take at most 20 seconds.  But if READ-CHAR-NO-HANG makes a RPC
-- and in the current model it must perform a RPC, otherwise the user
can't input anything -- then the loop can hang forever.  The user
should be allowed to send input (i.e. the REPL buffer should be in
read mode) even if the Lisp system is doing something unrelated.

I don't know what the expected result should be when other threads
request input.  A shell (with job control) blocks background processes
which want to read from the terminal.  E.g. a process started with

$> cat &

blocks until it is placed in the foreground.  Slime could have similar
commands to put threads in foreground/background.  Alternatively there
could be an explicit command to toggle between normal mode and read
mode, and if another threads requests input we could print some
message like: "Thread <foo> requests input. Press C-<bar> to switch to
read mode" or automatically switch to read mode and let the user
figure out when he wants to switch back to normal mode.

> 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.

A difference is that the current model is synchronous (Emacs is in
read mode only during read operations on the Lisp side) which is
unsuitable for READ-CHAR-NO-HANG.

Helmut.