Closed notgull closed 1 year ago
UnorderedFutures
seems to be a simpler version of futures
's FuturesUnordered
, but it's not clear to me how reasonable this is for this library, given the footgun in FuturesUnordered
.
Also, as we cover the many APIs that futures
has, eventually the benefits of this library will be lost...
You may be right; I wasn't aware of the footgun until now. In that case, I'll close this PR; however, we might want to explicitly document the best ways to concurrently run futures.
This PR adds a new type,
UnorderedFutures
, that stores and then polls a series of futures concurrently. I then go on to useUnorderedFutures
to implementfor_each_concurrent()
andtry_for_each_concurrent
, resolving #26.The implementation I use here is relatively inefficient. It uses two allocations per future stored; one for the
Container
, and another for the readiness flag. In addition, another allocation is added per poll for thewaker_fn
. Ideally, it would look more like this:Note that this would add a dependency on
libstd
andatomic-waker
, and would require unsafe code since it's impossible to get aPin<MutexGuard<T>>
from aPin<&Mutex<T>>
without unsafe code.However, since this is an implementation detail that can be resolved through a patch bump in the future, I decided to leave it with the as-is simple implementation.