Thank you for the links, Scott! At Tue, 14 Jun 2011 21:42:17 -0400, C. Scott Ananian wrote: > > (As a minor technical note: it appears that the implementation of > flattenHistory in figure 4 occurs in the wrong order. Worlds should > be committed from the root to the leaves, shouldn't they?)
In that example, the organization is a straight links so that may have been confusing but the general idea of worlds is somewhat like the nested transactions; it is a tree of worlds, and a mid-level worlds represents all the state changes occured all transient children worlds. And you sort of honor the top-level world; it could be considered the persistent object that represents non-revertable memory. During the process of commiting worlds from the leaf to root (which is the only direction allowed as not having the double-linked pointers helps simplifying the design and also helps the garbage collection, etc. btw) at any moment you can take the leaf world at that moment and view the state of the application from within the world, and you basically won't notice if the commiting process is ongoing. And when the commiting reaches the root, the state in the root is fully updated yet the user's view still does not change. So, at least it is not "wrong", I think. In one of the past implementation of worlds, Alex spent so much time to make the automatic coalesing of worlds work; Upon finalizing a world that is no longer referenced is reclaimed and all content in it gets pushed down to its children, and then these children get re-linked to the grand parent. This was effectively commiting data from parent to child. Yes, it indeed has some attractive nature in some situations. For example, let us say we have an application (model) that has some history but let multiple users observe the application. Let us say the chain of state is: TopW <-> W1 <-> W2 <-> W3 (Let's say <-> means these are doubly-linked.) The good thing about this is that we can actually give away any Ws to different users to observe the application; user A may be seeing the application from W3, and user B may be seeing it from W2 all see what they want to see. Now, while these worlds are held by them, somebody decides to start the flatten operation, and coalesces unneeded worlds into its children. Yes, now W1 is not needed anymore (as nobody is using it) and its changes can be pushed down to W2 and W2 may be re-linked under TopW. As long as the user B and user A are holding on to W2 and W3, they won't notice this has happened. When user B decides to release W2, it then can be coalesceed into W3 and still fine. But, it turned out this complicates the implementation so much, a disturbing sense that the tree structure may change under the hood, and notably, and often the parent pushed down too much information down to its children. With single-linked tree of worlds like this: TopW <- W1 <- W2 <- W3 each world holds a nice invariant of "I hold everything happens after I was created". Giving away the middle of chain to a user may be a bit confusing as his view suddenly changes when somebody initiate the flatten operation, however. (Well, this gets longer than I wanted. The bottom line is that yes, in some cases being able commit from root to leaves may be useful, but there is trade offs.) -- Yoshiki _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
