[slime-devel] Re: Lisp is not ready for requests from the REPL, can it be any other way?

[Helmut Eller]

Luke Gorrie <luke at bluetail.com> writes:

> My UI thoughts so far have been limited to "SLIME uses one thread for
> requests, but other threads can also do user input/output and enter
> the debugger". That way SLIME could be used to debug multithreaded
> programs. I don't know how to handle I/O from threads or how to keep
> order in Emacs if lots of threads go mad in Lisp - this seems like the
> main area for experimentation.
> 
> Thoughts?

The Lispworks editor seems to create a thread for each evaluation
request (commands ala C-x C-e).  Well, at least for the first 2
requests.  The 3 thread seems to be blocked or delayed.  So, when you
start 2 endless loops you get 2 threads.  The output of both threads
is printed in the "Output" buffer.  C-g interrupts/stops (not sure)
the first thread.  Pressing C-g a second time has no effect :-).

Edwin (the Emacs clone in MIT-Scheme) behaves in a similar way.  It's
customizable if the done an "inferior" thread or in the editor thread
itself.  The output goes usually to the REPL buffer (that's the moral
equivalent to Emacs *scratch*), but this is configurable.  Apparently
quite a few options; haven't tried them.  Debugging multiple threads
was very confusing, or at least I was unable to figure out how to do
it.

It would probably good if we provide this "evaluation in a separate
thread" as an option.

Helmut.