[slime-devel] Beginnings of multiple session support

Luke Gorrie luke at bluetail.com
Mon Jan 5 21:44:21 UTC 2004


Ahoyhoy,

Glad to see you all again in 2004, and what a lovely swag of christmas
patches to find under our tree :-)

I've checked in basic support for Emacs to have multiple connections
to Lisps simultaneously. Today this means you can connect to several
Lisps at the same time, and even concurrently debug different programs
like Peter described. For the future the plan is to try Gary Byers's
idea of using this as the basis of multithreading support.

The current user-interface is very minimal, only really usable for
testing. `M-x slime-connect' now gives you the option of keeping your
existing connections alive. If you have multiple connections, you can
cycle your "primary" connection (used for REPL, C-c :, and so on) with
`M-x slime-next-connection'. Various buffers, e.g. the debugger,
apropos results, etc, are "sticky" -- they will always use the
connection that they were created by.

Methinks the next step is to allow multiple REPLs and have `M-x slime'
support multiple *inferior-lisp*s.

For now it's best to wait before trying this out as a user. The
purpose of this mail is really to describe what I've done to the code,
not to advertise features that actually work well :-)

So - down to the code:

Previously we had just one "process" (socket), used for everything:

  (defvar slime-net-process nil
    "The process (socket) connected to the CL.")

But now we have many processes, one of which is in use at a time:

  (defvar slime-net-processes nil
    "List of processes (sockets) connected to Lisps.")
and
  (defvar slime-connection nil
    "Network process currently in use.")

`slime-net-processes' is for the low-level networking code to know
what connections we have so that we can poll them for input and so on.
`slime-connection' is the process that we should actually use to send
commands to Lisp.

We also recorded information about Lisp in global variables, like:

  (defvar slime-pid nil
    "The process id of the Lisp process.")

But globals don't cut it with multiple Lisps, so now these become
"connection-local variables". These variables are only used via
accessor functions, and are really kept as buffer-local variables
inside the process-buffer of each connection. For example:

  (slime-def-connection-var slime-pid nil
    "The process id of the Lisp process.")

Then we can say (slime-pid) to get the value for the current
connection (looked up in the process-buffer of `slime-connection' -
the currently active connection), and use (setf (slime-pid) ...) to
write it.

The cute part: because all connection-specific state is in
connection-local variables looked up indirectly, to "context-switch"
between connections we only have to rebind `slime-connection'. This
also means you can make a particular connection "sticky" for commands
in a given buffer just by making a buffer-local binding of
`slime-connection'. This is done in e.g. SLDB buffers to debug the
right Lisp.

My current plan is something like:

  More usable UI.
  Another round of backend refactoring, to pave the way for -
  Automatic connection-per-thread multiprocessing support.

Other notes/confessions:

  Each connection has a separate SLDB buffer.
  All connections share a REPL, but this is possibly wrong and
  definitely not working right.

Cheers,
Luke






More information about the slime-devel mailing list