Luke Gorrie luke@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.