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