POS

[BRIAN SPILSBURY]

> BRIAN SPILSBURY wrote:
> > It is transparent in that there is no difference to anything except for
> > the garbage collector, and that you can't guarantee that a weak-reference
> > won't suddenly point to nil at any given time. 
> 
> Right. So it isn't transparent to the system, the programmer or the
> user. It isn't transparent.

You must have a different definition of transparent to me, please tell
me what it is.

> What you seem to be discussing is persistency by *default* rather than
> transparent persistency. You must still think about persistence in many
> applications.

When I don't have to take persistence into account to interact with
objects then persistence _is_ transparent in my book.

The only point at which I might need to take persistence into account
is where I'm creating an object whose persistent characteristics are
not the default. And that is not terribly common, and certainly should
not be visible to the user.

> > Also _just_ having a transactional POS kills persistence of execution
> > entirely, which is something definately worth considering.
> 
> Executional persistence can be built on top of transactional systems.
> Hell, executional persistence can be built on top of *Unix*. The real
> question is what is the default.

Executional persistence requires underlying support in the memory
system. If you have a stack it must be preserved, if you refer to
anything outside that stack that is not necessarily referenced
though your transactional database you'll have trouble.

Executional persistence in unix is a nuisance, and sometimes unimplementable
simply because you may have libraries mapped in at different locations
in which case function pointers may now point into 'interesting' spaces.

To write a system with persistence of execution the only realistic way
that I've found is to first create a virtual memory system, ala mmap()
place your stack and everything else you use apart from shared libs in
there, and then _hope_ that you're not on a unix that happens to map libs
in at random locations. I guess you could compile it static. :)
But even then you can still lose state, think about something like strtok().

> 
> I have another underlying concern about this persistence-by-default
> proposal. What does memory maintenance look like to a user? In a OO DB I
> would expect to do queries for large objects or objects belonging to
> specific programs or search for objects by type. If I run out of disk
> space I delete *.jpg or something. But with persistence-by-default,
> things are not required to have names. My jpeg viewer might just have
> millions of jpeg files stored in its memory and if those objects are
> visibile to me *at all* they would not have names. "df" would return:

with persistence-by-default objects are required to be reachable, if
you're sane then you'll probably make up registeries for file-ish things.

If they're not the kind of things that you want to access from a
file-system then why should they have names? Given introspection it should
be relatively easy to trace the resources that are reachable from a given
point - ie the slots in an object, this can show you programs with memory
leaks. Given support from the garbage collector you can even get a list
of everything that directly references a given object.
 
> Jpview 100,000,000MB
> 	Jpeg-list-object
>             JPG 0X2321232 - 200,000MB
> 
> The useful things that I want to delete would also be mixed up with the
> ordinary program state variables that I am not interested in: "Window
> Position", "User Name" etc.

Think about a macintosh program. It has things called resources.
You can delete them if you like, just don't expect the program to
necessarily run afterward. Your point doesn't seem valid. If its
referenced by a program then that program should be using them, if its
not using them, then it shouldn't reference them.

> Yes, we could build a file system on top of a persistence-by-default
> system, but if most programs are going to do most of their work in the
> file system, why bother with the persistence-by-default?

Most programs don't need to use a file-system as a place to store files
reachable by others. A filesystem is only useful as a registry in which
other things can seek out stuff without you explicitely telling
them about it.

> In the end, how hard is it to keep a "state" object and just call a
> function (save-state state "path") and then (load-state state "path")?
> Just because Unix makes state loading painful does not mean we must make
> go to the other extreme and make it totally invisible.

Speaking from experience, almost completely impossible.

And whose talking about 'totally invisible'.
What I'm speaking about will give you as much visibility as you like,
which may be as much as unix (ie everything), or as little as possible
(ie nothing), or somewhere between where resources that should be
findable are findable via some registry/filesyste/thingy.

I personally lean toward the last.