Trait timely::progress::timestamp::PathSummary
source · pub trait PathSummary<T>:
Clone
+ 'static
+ Eq
+ PartialOrder
+ Debug
+ Default {
// Required methods
fn results_in(&self, src: &T) -> Option<T>;
fn followed_by(&self, other: &Self) -> Option<Self>;
}Expand description
A summary of how a timestamp advances along a timely dataflow path.
Required Methods§
sourcefn results_in(&self, src: &T) -> Option<T>
fn results_in(&self, src: &T) -> Option<T>
Advances a timestamp according to the timestamp actions on the path.
The path may advance the timestamp sufficiently that it is no longer valid, for example if
incrementing fields would result in integer overflow. In this case, results_in should
return None.
The feedback operator, apparently the only point where timestamps are actually incremented
in computation, uses this method and will drop messages with timestamps that when advanced
result in None. Ideally, all other timestamp manipulation should behave similarly.
§Examples
use timely::progress::timestamp::PathSummary;
let timestamp = 3;
let summary1 = 5;
let summary2 = usize::max_value() - 2;
assert_eq!(summary1.results_in(×tamp), Some(8));
assert_eq!(summary2.results_in(×tamp), None);sourcefn followed_by(&self, other: &Self) -> Option<Self>
fn followed_by(&self, other: &Self) -> Option<Self>
Composes this path summary with another path summary.
It is possible that the two composed paths result in an invalid summary, for example when
integer additions overflow. If it is correct that all timestamps moved along these paths
would also result in overflow and be discarded, followed_by can return None. It is very
important that this not be used casually, as this does not prevent the actual movement of
data.
§Examples
use timely::progress::timestamp::PathSummary;
let summary1 = 5;
let summary2 = usize::max_value() - 3;
assert_eq!(summary1.followed_by(&summary2), None);