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

Daniel Weinreb dlw at itasoftware.com
Fri Dec 17 20:31:23 UTC 2010



Jack Harper wrote:
> ...an interesting idea.
>
> Years ago (1984), I had dinner with Nils Nilsson (AI pioneer) and he mentioned the idea that he wanted to build a system that once alive would never be powered down again - in his view a minor but necessary prerequisite of an AI system.
>
> It will be interesting to see what people will say about how to do this.
This is so interesting that I would like to answer
it.  I apologize for the fact that none of this has
anything to do with Lisp per se.

What if the machine breaks or there is a power failure?

There has been some great work, I believe done
cooperatively by Stanford and U.C. Berkeley,
about how to deal with this.  Do a web search
for "crash-only systems".  What you have to do
is be able to quickly recover from such failures,
getting you back to the same state you were
in, or at least that latest state that you
decided to checkpoint.  Tecnology developed
for database management systems is very
helpful here.  Some of the more recent Linux
file systems have this property, ususally
implemented by what DBMS people call
redo-logging.

Bear in mind, though, that one reason people "reboot"
things is because they *want* to get rid of the
state, rather than to recover it!  But *which* state
should be reset and which should not?  In
traditional systems, some state is persistent,
which means stored in places like files or
DBMS's (or servers, sometimes), and the
rest is "transient" and gets reset on a reboot.

Doing this is very crude.  It just arbitarily
does things like setting global variables
to NIL or whatever their initial value was.
Why do you think *that* is a particulary
good thing to do?  Well, it has something
to do with the application programmer's
*reason* to decide what to store in a file/DBMS
and what not.

In the crash-only system, the good side is that you
can control this: you can just call a function
that resets whatever state you want to
not preserve.

The drawback is that you might not succeed in
enumerating all the ones that you'd like to see
reset.  So you might want to do something like
putting a declaration on those things that
you'd like to see reset (at those times when
you otherwise would have done a reboot).

At this point, you may notice that traditional
and crash-only systems are not as different
as they initially appeared.

I should think about this more and make it a
blog post, but first run it by the crash-only
guys...

-- Dan





More information about the pro mailing list