Brian Mastenbrook bmastenb@cs.indiana.edu writes:
What you're attempting to do requires threading. There has been work on that, described on the list. You might check the list archives. Hopefully within a month, you should be able to do just that :-)
I don't think we've discussed a UI that would support what Dirk wants. It sounds like separate threads for REPL and lisp-mode commands. I suppose ELI works like this with thread-per-request.
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?
BTW, this morning I got some multithreading working in CMUCL with the new connection-per-thread model. This is different to the previous incarnation in that different threads can talk to Emacs at the same time ("Peter Siebel style" :-)).
I have to understand SERVE-EVENT+threads better before it's usable/checkin'able, but I'll get something to experiment with in this week. Currently one thread seems to "starve" the other even while waiting on I/O, even with the sockets set non-blocking. If I can't fix that quick I'll try SBCL.
-Luke