timely: unconstrained lifetime for CapabilityRef
#491
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since the merge of #429,
CapabilityRef
s have been made safe to hold onto across operator invocations because that PR made sure that they only decremented their progress counts onDrop
. While this allowedasync
/await
based operators to freely hold on to them, it was still very difficult for synchronous based operators to do the same thing, due to the lifetime attached to theCapabilityRef
.We can observe that the lifetime no longer provides any benefits, which means it can be removed and turn
CapabilityRef
s into fully owned values. This allows any style of operator to easily hold on to them. The benefit of that isn't just performance (by avoiding theretain()
dance), but also about deferring the decision of the output port a given input should flow to to a later time.After making this change, the name
CapabilityRef
felt wrong, since there is no reference to anything anymore. Instead, the main distinction betweenCapabilityRef
s andCapabilities
are that the former is associated with an input port and the latter is associated with an output port.As such, I have renamed
CapabilityRef
toInputCapability
to signal to users that holding onto one of them represents holding onto a timestamp at the input for which we have not yet determined the output port that it should flow to. This nicely ties up the semantics of theInputCapability::retain_for_output
andInputCapability::delayed_for_output
methods, which make it clear by their name and signature that this is what "transfers" the capability from input ports to output ports.