async Read/Write: should we support a way to load multiple IOs on a single epoll (or whatever)

[nrc]

I.e., rather than having optimal code write a ready loop and wait for multiple ready calls, we have some abstraction which lets us add many resources and then wait for all of them at once (using a single call to epoll under the covers). It's possible the executor can do this implicitly (perhaps some do already), or its possible that there is not much performance benefit to doing this. But it might be something that is useful.

[NobodyXu]

An interesting case here will be the multishot recv operation from io-uring, where recv is only issued once and it just keep reading.

[joshtriplett]

@nrc To the best of my knowledge, there's a substantial benefit to doing this at scale: having one call to epoll with a thousand file descriptors, rather than a thousand calls with one file descriptor.

[NobodyXu]

@nrc To the best of my knowledge, there's a substantial benefit to doing this at scale: having one call to epoll with a thousand file descriptors, rather than a thousand calls with one file descriptor.

And io-uring also has provided buffer, which solves the problem of reading from multiple fds while sharing the buffer.

[uazu]

In the executor it's essential, or else it can't support several tasks waiting at once.

The question is whether it's worth exposing that in an API. Async/await code has a problem expressing waiting for several things at once. I think the idea in this model is to have a task for each and then join. (Coming from an actor-model background, this seems awkward.)