It seems like for most people, input order isn't that important for
concurrent work, and concurrent results being in non-deterministic order is
often expected.
If mapConcurrent() just respect output encounter order:
It'll be able to achieve *higher throughput* if an early task is slow, For
example, with concurrency=2, and if the first task takes 10 minutes to run,
mapConcurrent() would only be able to process 2 tasks within the first 10
minutes; whereas with encounter order, the first task being slow doesn't
block the 3rd - 100th elements from being processed and output.
mapConcurrent() can be used to implement useful concurrent semantics, for
example to *support race* semantics. Imagine if I need to send request to
10 candidate backends and take whichever that succeeds first, I'd be able
to do:
backends.stream()
.gather(mapConcurrent(
backend -> {
try {
return backend.fetchOrder();
} catch (RpcException e) {
return null; // failed to fetch but not fatal
}
})
.filter(Objects::notNull)
.findFirst(); // first success then cancel the rest
Cheers,
