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

[Peter Seibel]

Luke Gorrie <luke at bluetail.com> writes:

> Brian Mastenbrook <bmastenb at 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?

I'm not sure I understand what you mean by "lots of therads go mad in
Lisp". Do you mean, they generate a lot of output. I assumed that each
Lisp thread would have a buffer in emacs where it's output went. But
maybe you're talking about something else.

> 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" :-)).

:-)

-Peter

-- 
Peter Seibel                                      peter at javamonkey.com

         Lisp is the red pill. -- John Fraser, comp.lang.lisp