Branch Scheduling #226
Branch Scheduling #226
Conversation
distsys/archetypeinterface.go
Outdated
| iface.ForkedResources[forkedHandle] = forkedResource | ||
| } else { | ||
| // Parent iface had the resource so link its state | ||
| err := forkedResource.LinkState() |
There was a problem hiding this comment.
imo, this method should not exist. I think there's another way, where you just manipulate the maps and nothing else, until commit.
distsys/archetypeinterface.go
Outdated
| iface.ForkedResources[forkedHandle] = forkedResource | ||
| } else { | ||
| // Parent iface had the resource so abort its state | ||
| err := forkedResource.AbortState() |
There was a problem hiding this comment.
similar theme as LinkState, why isn't this just Abort?
distsys/archetyperesource.go
Outdated
| } | ||
|
|
||
| func (res *LocalArchetypeResource) LinkState() error { | ||
| res.forkParent.value = res.value |
There was a problem hiding this comment.
following on for why this method should not exist imo, notice how there would be literally no difference if you just kept one of the forked resources, vs doing a field by field full copy here.
…to ruchitp-branch-scheduling
…g "complicated" example in incmap.go. Warning: this will not compile!
…to ruchitp-branch-scheduling
| // ForkState provides a copy to the ArchetypeResourceState such that operations performed on other ArchetypeResourceStates | ||
| // with the same parent ArchetypeResource will not cause side effects for the current ArchetypeResourceState. | ||
| // ForkState will clone all the parts of a resource whose properties are NOT idempotent. A call to ForkState | ||
| // creates the expectation that there will be an eventual call to Commit/Abort on the resulting ArchetypeResourceState |
There was a problem hiding this comment.
Suggested rephrasing:
ForkState will clone all the parts of a resource whose properties are NOT idempotent.
ForkState should create a separate copy of any thread-local data held by the original ArcvhetypeResourceState. It is the responsibility of the implementation to ensure side-effects that are not thread-local are synchronized and maintained correctly, given that the two forked versions will be accessed by different goroutines.
|
@fhackett should we close? |
No description provided.