Unordered Async Iterator Helpers for Stage 1

Michael Ficarra • July 2024

background & motivation

iterator helpers

async iterator helpers

unordered async�iterator helpers

(this proposal)

concurrency control

dropping ordering constraint improves throughput

image credit: https://github.com/alexpusch/rust-magic-patterns/blob/master/rust-stream-visualized/Readme.md

the proposal

Iterator� .prototype

• .toAsync
• .map
• .filter
• .take
• .drop
• .flatMap
• .reduce
• .toArray
• .forEach
• .some
• .every
• .find

AsyncIterator

.prototype

• .unordered
• .map
• .filter
• .take
• .drop
• .flatMap
• .reduce
• .toArray
• .forEach
• .some
• .every
• .find

​

• .map
• .filter
• .take
• .drop
• .flatMap
• .reduce
• .toArray
• .forEach
• .some
• .every
• .find

UnorderedAsyncIterator� .prototype

example

someAsyncIterator� .unordered()� .map(...)� .filter(...)� .take(...)� .toArray(..., governor)

what does Stage 1 mean for this proposal?

• find a way to provide more performant async iterator helpers when it is okay to drop the ordering constraint
• covered concretely in this proposal through the addition of an .unordered() method to AsyncIterator.prototype and the introduction of UnorderedAsyncIterator.prototype
• should be easy and convenient to use (because we expect it to be common)
• should not be easy to accidentally mix with ordered helpers

​

NOTE: Because unordered helpers provide no advantage in the absence of concurrent calls to .next(), the iterator-consuming methods in this proposal (.some(), .forEach(), etc) will depend on the Concurrency Control proposal.

Stage 1?

• should the names of .toAsync() and .unordered() match better?
• AsyncIterator.prototype.toUnordered()?
• Iterator.prototype.async()?
• should UnorderedAsyncIterator.prototype have a .unordered() method?
• likewise, should {Unordered,}AsyncIterator.prototype have a .toAsync()?
• require the concurrency parameter?
• concurrency of 1 is basically like calling an ordered helper (bad)

​

open design questions (if we have time)