[slime-devel] stateless-emacs

[Helmut Eller]

Luke Gorrie <luke at bluetail.com> writes:

> Ahoy,
> 
> I have checked in my majorly hacked version on a new branch called
> `stateless-emacs'. If anyone wants to take it for a spin that would be
> helpful for flushing out problems not covered by the test suite. There
> is a STATELESS-EMACS tag set at the point where I branched.

I'm working on this version and changed the CMUCL backend to use
signal driven IO.  This means that M-. works now even during a
compilation.  It's even possible to compile when CMUCL is already
compiling :-), but it shouldn't be too difficult to disable unwanted
nested evaluations.  The advantage of signal driven IO is, that the
Lisp side can respond to requests at any moment.  For instance,
interrupting is now more or less a normal message and we don't need
Unix signals for IPC.  This should also work on remote hosts.

I'm now adding similar functionality for mutlithreaded Lisps.  My plan
looks like this: we have 3 communicating threads, a "reader", a
"control" thread and a "worker" thread.  The "reader" reads request
from the socket and sends them to the "control" thread.  The control
thread dispatches requests to worker threads and handles interrupt
requests.  Currently I create a new worker thread for most requests,
but interrupt and debugging messages are sent to the appropriate
worker thread.  A worker thread executes the request and sends the
result back to the controller and the controller sends the result to
Emacs.  A worker only communicates with the controller and doesn't
write directly to the socket.  Many messages include now a thread
field, so that Emacs knows which thread to talk to.

The thread-per-request support is implemented for SBCL, Lispworks, and
Allegro.  The SBCL version doesn't work very well, apparently some
deadlock problem.  Will probably switch to signal driven IO for SBCL.
An OpenMCL port should be easy.  Haven't decided yet what to do with
CLISP.  I tried to add signal driven IO for CLISP, but SIGIO is
blocked in the SIGIO handler and I get segfaults when I set the
SA_NODEFER flag.

I'm also thinking about a possibility to query the state of the Lisp
side.  The idea is that Emacs receives a list describing the
interesting bits of Lisp's current call stack.  That would be very
useful for writing test cases and perhaps something like a resync
command.  It would be nice if Lisp could answer such
'get-current-state' requests immediately; it should be treated like an
interrupt request.

My question now is: can we assume that Lisp can answer such requests
immediately?

It's probably difficult to implement this for CLISP, but it would
reduce the complexity of the Emacs side.

Helmut.