pub struct Executor { /* private fields */ }Implementations§
Source§impl Executor
impl Executor
pub fn new(parallel: i64) -> Result<Self>
Sourcepub fn parallel(&self) -> usize
pub fn parallel(&self) -> usize
How many workers, which is also how many batches the readers split a request into.
Sourcepub fn install<R: Send>(&self, f: impl FnOnce() -> R + Send) -> R
pub fn install<R: Send>(&self, f: impl FnOnce() -> R + Send) -> R
Run f on the pool. Rayon calls made inside it use these threads rather
than the global pool, which is what keeps one reader’s parallel a
promise about this reader.
Sourcepub fn spawn(&self, f: impl FnOnce() + Send + 'static)
pub fn spawn(&self, f: impl FnOnce() + Send + 'static)
Hand one job to the pool and return without waiting.
What the writer’s deflate pipeline is built on: a block is submitted, the caller goes on filling the next one, and the result is collected in submission order later. Everything else here is fork-join, which does not fit a producer that has to keep producing.
Sourcepub fn for_each_batch<T: Send + Sync>(
&self,
batches: &[T],
f: impl Fn(usize, &T) -> Result<()> + Send + Sync,
) -> Result<()>
pub fn for_each_batch<T: Send + Sync>( &self, batches: &[T], f: impl Fn(usize, &T) -> Result<()> + Send + Sync, ) -> Result<()>
Run one job per batch, collecting the first error.
Batching is the caller’s: IndexedLocs::batches splits loci into
coverage-balanced groups, and that split decides which blocks each
worker touches and so how much of the cache is shared. Letting rayon
work-steal its own split would change both, and with them the order
f32 accumulators are summed in — which is visible in the last bits of
every mean and standard deviation.
Sourcepub fn map_batches<T: Send, B: Send + Sync>(
&self,
batches: &[B],
f: impl Fn(usize, &B) -> Result<T> + Send + Sync,
) -> Result<Vec<T>>
pub fn map_batches<T: Send, B: Send + Sync>( &self, batches: &[B], f: impl Fn(usize, &B) -> Result<T> + Send + Sync, ) -> Result<Vec<T>>
The same, keeping each batch’s result in submission order.
What the extraction kernels use: a batch’s loci own scattered slices of the output, not a contiguous one — the loci are sorted into file order while their output slices follow the request’s order — so each worker fills a compact buffer of its own and the caller scatters afterwards. That keeps every bin accumulated by exactly one worker in one order, which is what makes the result bit-reproducible.
Trait Implementations§
Source§impl Debug for Executor
Hand-written: rayon::ThreadPool is not Debug, and a reader that holds an
executor still has to be printable.
impl Debug for Executor
Hand-written: rayon::ThreadPool is not Debug, and a reader that holds an
executor still has to be printable.
Auto Trait Implementations§
impl !RefUnwindSafe for Executor
impl !UnwindSafe for Executor
impl Freeze for Executor
impl Send for Executor
impl Sync for Executor
impl Unpin for Executor
impl UnsafeUnpin for Executor
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Source§impl<T> IntoEither for T
impl<T> IntoEither for T
Source§fn into_either(self, into_left: bool) -> Either<Self, Self> ⓘ
fn into_either(self, into_left: bool) -> Either<Self, Self> ⓘ
self into a Left variant of Either<Self, Self>
if into_left is true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read moreSource§fn into_either_with<F>(self, into_left: F) -> Either<Self, Self> ⓘ
fn into_either_with<F>(self, into_left: F) -> Either<Self, Self> ⓘ
self into a Left variant of Either<Self, Self>
if into_left(&self) returns true.
Converts self into a Right variant of Either<Self, Self>
otherwise. Read more