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