[−][src]Trait timely::progress::timestamp::PathSummary

pub trait PathSummary<T>: Clone + 'static + Eq + PartialOrder + Debug + Default {
    fn results_in(&self, src: &T) -> Option<T>;
    fn followed_by(&self, other: &Self) -> Option<Self>;
}

A summary of how a timestamp advances along a timely dataflow path.

Required methods

`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(&timestamp), Some(8));
assert_eq!(summary2.results_in(&timestamp), None);

`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);