On Sat, 13 Dec 2003, Helmut Eller wrote:
I think multi-threading support should "feel" like job-control in a shell. Usually you only interact with the foreground thread. There should be the possibility to interrupt the foreground thread if it is busy, to place it in the background, and to switch to another thread. Only the foreground thread should be allowed to pop up buffers and to read from the REPL. The output can probably be mixed and just be inserted in the output buffer.
If all threads are sharing the same value of *TERMINAL-IO* etc in some way shape or form, that's probably what it does feel like. (In OpenMCL's case, it feels like "job control that doesn't always work right and can't be as hard to get right as it seems"; in some other multithreaded lisps that I've used, it feels like "job control that may act predictably and reliably but which some people find totally unintuitive", and in other multithreaded lisps it may feel like "job control that works reliably and intuitively".)
SLIME does seem to offer other ways of presenting interactive output from, interactive input to, and debugging support for lisp threads. Naively (I confess to not having done my SLIME homework), it doesn't -seem- that starting a second (or third or Nth) SLIME REPL (with associated debugging and auxiliary buffers) needs to be a whole lot different than starting the frst session was, and whether the lisp thread on the other end of the connection is one of many in a multithreaded lisp or the only thread in another instance of a single-threaded lisp or ... probably needn't matter too much from SLIME's point of view. If SLIME already support the notion of multiple sessions (within a single running [X]Emacs), then I think that the hard work of supporting this style of interaction's already been done; if it doesn't currently support multiple sessions, then some of that hard work might involve deciding on policy matters (e.g., which REPL do editor commands interact with ? how is this changed ?).
To what extent can/should a SLIME REPL be decoupled from "an Emacs stream connected to a remote Lisp stream on one end and to an Emacs buffer on the other" ? (Pretty obviously, these things are already decoupled, but it might be nice to mix and match: I could imagine wanting to use SLIME's debugger, even if a given session/thread wasn't running a SLIME REPL (or any other REPL, for that matter.)
There are lots of cases where I think it'd be handy to create an IPC connection to [X]Emacs from the lisp side: to be able to create from lisp a stream whose output appeared in and/or input came from an Emacs buffer. One could almost imagine as many uses for this capability in single-threaded lisps as in multithreaded ones. (Those uses are maybe a little more obvious in the latter case.)
Sorry if I'm raisng questions that could be easily answered by looking at the SLIME sources more carefully than I have. I think that it's worth noting that a lot of the issues related to some kinds of "SLIME-interaction-with-multithreaded-lisps" are common to "SLIME-multiple-concurrent=session-support". Whatever that is, exactly ....
Helmut.
Gary Byers gb@clozure.com