[pro] How to interact with a running lisp instance?

Daniel Weinreb dlw at itasoftware.com
Fri Dec 17 20:21:34 UTC 2010


It depends on what you mean by "interact".  Is it a program
interacting or a human interacting.  If you mean the latter, then
Swank makes sense.  If the former, Swank isn't needed and is probably
overkill As Sam Steingold says:

    A less generic answer would be to start an extra thread which would be
    listening on a port and then you can connect to that port to get a
    lisp prompt without interrupting all the other processes currently

So you'd only need a REPL talking to a stream.

Or you could send a form by HTTP.  That can help with some problems.
If you just have REPL on a stream, the boundary between forms is
entirely ruled by the Lisp reader, and if there's any confusion
between the client and the server about this (think "reader macros"!),
then you could get out of sync and the whole thing stops working.
HTTP gives you boundaries that you can re-sync to.  There are nice
portable Common Lisp package for both client (drakma) and server
(hunchentoot).

In our own Common Lisp servers, we actually do both We have two things
that we use for debugging or for emergency patching:

(1) Swank is pre-loaded into the server, so if we want to get in and
look around, we can run Emacs with slime, and tell slime to connect
over a TCP connection.  As Gail points out, you have to be careful to
use the version of Slime that corresponds to the version of Swank that
was pre-loaded.  We do not upgrade very often so that hasn't been a
problem in practice but you definitely have to do that right.

(2) We have a simple way to send one HTTP request with a Lisp form in
it, which is read and evaluated.  (Zach suggested this.)  This is ONLY
for emergencies, i.e. it must be done quickly, e.g. because your
system must be highly available.

You have to be very careful with this general eval mechanism.  If
there were time enough to test the fix, then we would not use this
mechanism at all.  We'd do the fix, commit it into the source control
system, rebuild the code, and do a "hot upgrade", basically a rolling
upgrade across the cluster of servers.  There are version issues that
you have to worry about here, and we have official guidelines about
how to deal with that.  Ryan Davis's reply about this went into
detail and I agree with him 100%.  David Owen's reply, I believe,
was in respect to a setup where you aren't using clustering.

Ala'a Mohammad said:

    I just want to point to another possibility, however, it's specific to
    CMUCL using the remote package

    http://common-lisp.net/project/cmucl/doc/cmu-user/ipc.html

I haven't looked, but I would guess that using drakma and hunchentoot,
it could be easy to make this portable between CL implementations.

-- Dan





More information about the pro mailing list