POS

[Paul Prescod]

BRIAN SPILSBURY wrote:
> > support, but not *file system support*. Why not just have a function:
> > "(save-my-state)" that saves the current state. In fact, in Scheme I
> > would write it this way:
> >
> > (define (save-my-state path)
> >       (call-with-current-continuation
> >               (lambda (continuation) (write continuation path))))
> >
> > That requires a standard format for continuations, of course.
> 
> That's fine, now tell me when I press my shiny 'shutdown button'
> do I then go and say 'hellllloooooooooo, everyone do your persistence
> stuff, because the power is going away'. Then I need additional mechanism
> to manage this, and I need programs to comply with protocols, and eventually
> I may need to turn off the power not being sure that everyone has
> persisted stuff. I'd call this a bad thing(tm).

That's not true. You hit the "shutdown button" and the operating system
store each processes state, byte by byte. This need not have ANYTHING to
do with the processes usual mechanisms for persistence. Your typical
$1000.00 laptop does this with operating systems as brain-dead as
Windows 95. I have been told that the reason desktop computers do not do
it properly is because of device driver initialization problems, but a
new, from-scratch OS should be able to put sufficient distance between
apps and devices that this is no longer a problem.
 
> > Right. I think that everything should go into the registry so that users
> > can manage it from standard programs ("ls", "df").
> 
> Agreeed, in which case that's your standard way to find stuff, and all
> done at the user level, which means that I can replace it with a 6 dimensional
> frisbee oriented system later on if I so choose.

My point is that we've reintroduced much of the work that seemed like it
would magically "go away" if we didn't have to deal with files. As long
as users maintain their own hard disks, applications will have to deal
with filenames and meta-data (e.g. paths). What we *can* get rid of is
the painful step of manually recreating objects from bytes.

There will also be the temptation to NOT register data in the
filename/OO-system registry. "My web-browser program's state is taking
up 20MB!!! There is this array called *crobjstack* in the middle of an
object called *cslistwatcher* that is 19MB but I don't know what it is."
The traditional requirement for software developers to explicitly place
things in the user space (the file system) results in them giving things
reasonable names.
 
> Calling it is the problem. Especially when you want a chance to recover when
> that idiot in the next cubicle accidently unplugs your machine to make
> the the coffee machine go.

It is possible (but rare) that the system could lose power when it is in
an uncertain state where one object has sent a message and another has
not received it. Personally, I am not willing to take a performance hit
in order to get around this relatively rare problem. I don't even want
to think about what garbage collection of a 7GB drive looks like.

To summarize:

#1. If something is important enough that it should survive a reboot,
give it a NAME. An OOFS (instead of a Transparent Persistent Store)
enforces this. A "transparent store" that requires everything to have
user-level names isn't that transparent anymore. You must still do a
bunch of the work you were hoping to avoid: naming things and organizing
pointers.

#2. If you want to shut down and store EVERYTHING (which is a good idea)
then that can be done by the operating system with no special filesystem
or application support. But between shutdowns you don't need to store
everything so you can actually save some disk space (equivalent to the
amount of RAM you have).

#3. If a particular execution thread wants to shut itself down and store
all of its data it can do so in a standard OOFS by saving its
continuation. Those who have a good reason for wanting apps that do not
explicitly name their data can use this mechanism (I think that this is
rare).

#4. If you shut down your machine between the time when one execution
thread has done a checkpoint and a related thread has done a checkpoint
then a message passed between them may be lost. I believe this to be
unavoidable on multithreaded operating systems that can work across
processors. I think it will also happen on an "implicit commit" system
that has any period of delay between implicit commits (which is
unavoidable).

 Paul Prescod