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.
At the moment, any data sent through a Timely stream needs to be
Clone
becauseTee
needs to be able to clone data to send it to multiple recipients. This change tries to change this, although it comes with far-reaching and breaking changes.I don't intend to merge this yet, but it seems like a solid basis for further experiments.
Specifically, it introduces new types and changes behavior:
OwnedStream
that can only be connected to one downstream operator. Because of this, there's noTee
involved that would require data to beClone
.Tee
,OwnedStream
has atee
function that returns a stream that can be shared between downstream operators. This function requires the data to beClone
and just like all other operators consume the stream.StreamLike
type to be generic overOwnedStream
andStreamCore
. This requires a few more type parameters here and there.Clone
requirement fromContainer
. This adds a bound+Data
requirement to all operators that want to take ownership of their container input (which is all operators.)The effect of this change is that for
op --> op
structures, we only have a vcall where we currently have a vector dereference plus vcall. This can be better in some situations, but I didn't measure it. The downside is that requesting atee
adds the vector dereference plus vcall after the first vcall, so it's strictly worse. This should be amortized by how infrequently it's used, but who knows.In theory, we don't need the vcall at all because the type of the downstream operator is known to Rust and hence its pusher. However, I currently can't see how to wire it up, and I believe it's ugly because the information needs to flow backwards from the receiving operator to the source.