But then you have a journaling object store _and_ some method for the
OS to determine dependency chains in arbitrary objects. Even on a single
computer, this is hard. Object D is a "directory" object exporting
methods for accessing objects listed in the directory. One of those objects,
object R is a relational database table that references object R' a second
table, not listed within D, and also has some dynamic content provided by
object C also not listed in D. We now "move" the listing of R to D' and
ask the OS to "write D and D' and all their dependents atomically!
Simple as pie -- especially if D' is over the network.
State is hard. Much of academic CS over the last 20 years is an effort
to hide state and hope that what you don't see won't bite you. (EROS
is has some good ideas, but I verymuch doubt Shapiro would argue that it
makes state complexity disappear).
> > Why is having persistence managed by a library that is playing guessing games
> > of your intent a good idea ? It has to know about object relationships,
> > potentially it has to blindly snapshot the entire system. It has to do a lot
> > of work to know in detail what has changed.
>
> For the *exact same* reasons that automatic memory management with
> garbage collection is preferable to slinging your own buffers. Perl
> and Python and Tcl are on the rise because, outside the kernel, accepting
> all that complexity and the potential for buffer overruns just doesn't
> make any damn sense with clocks and memory as cheap as they are now.
Yes. In different domains, different paradigms make great sense.
> > So all you have to do is export every object that this object refers to. Like
> > the windowing environment, whoops oh dear.
>
> Now you know it's not that bad in practice. Not all object references are
> pointers. Some are capabilities and cookies that are persistent without
> prearrangement. That's especially likely to be true of OS services, and
> especially if you design your API with that in mind.
But the OS, in your scheme, must accomodate the most complex cases.
> > system at the bottom of an environment you prevent the smart programmer doing
> > smart things. If your bottom layer is fundamentally ignorant of programmer
> > provided clues you cripple the smart.
>
> If that's true, why is Perl a success?
Because it uses a simple bottom layer in a clever way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/