> That depends on if you want to consistency check your object store after a
> crash. Unless you journal the object store - which btw is hard. If you have
> two thousand inter-related objects you need to dump the set of them
> consistently and in a snapshotted state.
I've been thinking about this since your last post. Seems to me the primitive one needs is the ability to say "This object and all its dependents need to be written atomically". Not too hard to imagine how to do that given you already have enough of a VM system to do copy-on-write. OK, you end up having to allocate in two different spaces, one with atomicity constraints and one without. But it's solvable. (See below on why this doesn't mean you end up journaling everything).
> 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.
Remember, the name of the game in OS design is really to optimize for least complexity overhead for the *application programmer* and *user*. If this means accepting a marginally more complex and less efficient OS substructure (like the difference between a journaled object store and a file system with explicit I/O) then that's fine. But in fact I think Shapiro makes strong arguments that an object store, done properly, is *more* efficient.
> 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.
> Suppose Eros was just a set of persistent object libraries that ran on
If that's true, why is Perl a success?
> top of numerous other platforms too, could be downloaded off the net and
> pretty well within the limits of the "programmer lazy, do more work than
> worked needed" paradigm.
> And that is demonstrably the right way up. If you put a "lazy programmer"
> 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?
That's not intended to be a snarky question. Your argument here is essentially the argument for malloc(3) as opposed to unlimited-extent types and garbage collection. And the answer is the same: there comes a point where the value of the optimization you can do with hints no longer pays for the complexity overhead of having to do the storage management yourself.
The EROS papers implicitly argue that we've reached that point not just in memory management but with respect to the entire persistence problem. I'm inclined to agree with them.
At the very least, it's something that I think we'd all be better off doing a little forward thinking about. As I said at the beginning of the thread, I'm not after changing the whole architecture of Linux right away; that would be silly and futile. But this exchange will have achieved my purposes if it only plants a few conceptual seeds.
-- Eric S. Raymond The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org Please read the FAQ at http://www.tux.org/lkml/