Trait jobsteal::iter::Spliterator [] [src]

pub trait Spliterator: Sized {
    type Item;
    type Base: Split;
    type Consumer: Consumer<Self::Base, Item = Self::Item>;
    fn destructure(self) -> (Self::Base, Self::Consumer);

    fn cloned<'a, T: 'a + Clone>(self) -> Cloned<Self>
        Self: Spliterator<Item = &'a T>
, { ... } fn enumerate(self) -> Enumerate<Self> { ... } fn filter<F: Sync>(self, pred: F) -> Filter<Self, F>
        F: Fn(&Self::Item) -> bool
, { ... } fn flat_map<U, F: Sync>(self, flat_map: F) -> FlatMap<Self, F>
        U: IntoIterator,
        F: Fn(Self::Item) -> U
, { ... } fn map<F: Sync, U>(self, map: F) -> Map<Self, F>
        F: Fn(Self::Item) -> U
, { ... } fn zip<B: IntoSpliterator>(self, other: B) -> Zip<Self, B::SplitIter> { ... } fn any<P: Sync>(self, spawner: &Spawner, pred: P) -> bool
        P: Fn(Self::Item) -> bool
, { ... } fn all<P: Sync>(self, spawner: &Spawner, pred: P) -> bool
        P: Fn(Self::Item) -> bool
, { ... } fn for_each<F>(self, spawner: &Spawner, f: F)
        F: Sync + Fn(Self::Item)
, { ... } fn collect<T: Send>(self, spawner: &Spawner) -> T
        Self::Item: Send,
        T: FromIterator<Self::Item> + Combine + Send
, { ... } fn fold<F: Sync>(
        spawner: &Spawner,
        initial: Self::Item,
        folder: F
    ) -> Self::Item
        F: Folder<Self::Item>,
        Self::Item: Send
, { ... } fn size_hint(&self) -> (usize, Option<usize>) { ... } fn with_cost_mul(self, mul: f32) -> CostMul<Self> { ... } }

A parallel iterator which works by splitting the underlying data and sharing it between threads.

Functions which consume the iterator will take a &Spawner as an argument, so that they can distribute their work in parallel.

These can be used almost exactly the same as Rust's regular Iterators, with adapters like enumerate, map, filter, and more along with consumers like for_each and collect.

This trait may seem complicated to implement, but fear not! It is automatically implemented for data which implements Split, which is a lot easier to implement.

Spliterator only needs to be manually implemented by those who are trying to make their own adapters. Those individuals may want to look at the source of iterator adapters like Map and Filter. The good news is that all the Spliterator adapers are implemented using only public and safe jobsteal code, so anybody can create their own. The bad news is that it does get fairly complex.

Associated Types

The item this iterator produces.

The splittable base data which this consists of.

A consumer which can act as an ad-hoc iterator adapter chain while being shared across threads.

Required Methods

Destructure this iterator into a splittable base and a shareable consumer of that base.

Provided Methods

Clone the items of this iterator to get owned copies.

Enumerate items by their index.

Filter items by some predicate.

Produce an iterator for each element, and then yield the elements of those iterators.

Map the items of this iterator to another type using the supplied function.

Zip this iterator with another, combining their items in a tuple.

Whether any of the elements fulfill the supplied predicate.

Whether all of the elements fulfill the supplied predicate.

Consume this iterator, performing an action for each item.

Collect the items of this iterator into a combinable collection.

Note that this works by repeatedly combining the results of from_iter, so this will probably lead to more allocations than a single-threaded iterator collect.

Fold the items of the iterator together with the given operation and initial state.

Note: For this to work in parallel, the implementation assumes that the operation is commutative.

There will not be any safety issues caused by non-commutative operations, but there may be some incorrectness.

A lower bound and optional upper bound on the size of this iterator.

Uses a cost multiplier for this iterator.

This takes the absolute value of the multiplier supplied.

This will affect how often the data backing this iterator is split in two.

with_cost_mul(1.0) will have no effect.

with_cost_mul(2.0) will cause twice as much splitting, while with_cost_mul(0.5) will cause half as much splitting.

with_cost_mul(0.0) will cause the data to never split, and with_cost_mul(f32::INFINITY) will cause the data to split whenever possible.