When creating a new value chain in an MSV, we ensure that every ancestor of the value chain is constructed first (from the top-level VC on down) to avoid races. For all VCs other than read-only snapshots (ROSSes), the value chain holds a pointer to the parent VC. For ROSSes, the value chain just computes the value and doesn't hold a pointer, but the parent is necessarily there anyway and will remain as long as the ROSS VC does, because the ROSS view holds a reference to its parent.
For non-publishable snapshots (i.e., read-only and detached), there's actually no need to create VCs for any ancestors that aren't there when we look. If they're not there, they don't have a value now, and they certainly didn't when the snapshot was taken, so we can safely assume that their value as of the snapshot time is that of their parent (perhaps at an earlier time if they are also a snapshot).
So when constructing an unpublishable s/s VC, we can pass in the (typed) MSV as a ctor param and simply ask for parents until we find a view that has a VC to establish the value at the s/s time. For detached snapshots, we could even delay doing this until read time by caching the MSV in the VC. That would get rid of the cost for MSVs where the first operation on a detached snapshot VC was a non-reading write. We can do the chain lookup racily at any time, since we know the value can't be changed by anything that happened after the VC was created.
[imported from HPE issue 356]
When creating a new value chain in an MSV, we ensure that every ancestor of the value chain is constructed first (from the top-level VC on down) to avoid races. For all VCs other than read-only snapshots (ROSSes), the value chain holds a pointer to the parent VC. For ROSSes, the value chain just computes the value and doesn't hold a pointer, but the parent is necessarily there anyway and will remain as long as the ROSS VC does, because the ROSS view holds a reference to its parent.
For non-publishable snapshots (i.e., read-only and detached), there's actually no need to create VCs for any ancestors that aren't there when we look. If they're not there, they don't have a value now, and they certainly didn't when the snapshot was taken, so we can safely assume that their value as of the snapshot time is that of their parent (perhaps at an earlier time if they are also a snapshot).
So when constructing an unpublishable s/s VC, we can pass in the (typed) MSV as a ctor param and simply ask for parents until we find a view that has a VC to establish the value at the s/s time. For detached snapshots, we could even delay doing this until read time by caching the MSV in the VC. That would get rid of the cost for MSVs where the first operation on a detached snapshot VC was a non-reading write. We can do the chain lookup racily at any time, since we know the value can't be changed by anything that happened after the VC was created.