Conditionally use more efficient strategies for polling file I/O

[notgull]

For Windows there is file completion (for some operations, we'd have to fall back to blocking for others), for Linux there is io_uring and for BSD there is aio. It would be nice to use one of these strategies instead of the inefficient blocking code if they are available.

[nazar-pc]

Is IOCP an option for files on Windows?

I have a use case for doing 32k reads of 32 bytes and need to do it fast. On Windows with blocking I/O on a thread pool it is not fast at all comparing to Linux.

I might also be able to get a grant for this work if it is something of interest.

[notgull]

Is IOCP an option for files on Windows?

I have a use case for doing 32k reads of 32 bytes and need to do it fast. On Windows with blocking I/O on a thread pool it is not fast at all comparing to Linux.

I might also be able to get a grant for this work if it is something of interest.

I would very much appreciate this being worked on, as I don't have time for this at the moment. IOCP is an option for reading and writing files, along with some other operations that unfortunately don't include opening files. It may be faster than reading files using thread-based operations in some cases.

Here is a checklist of things that would need to happen in order for this to work:

• Finish this PR, which is needed for completion packets to be used in the greater async system.
• Expose this in async-io.
• Take advantage of this in async-fs.

[notgull]

@nazar-pc Any updates?

[nazar-pc]

I have done experiments with other async I/O libraries (glommio, monoio) and found out that even if it is faster for reads, I have reads interleaved with compute and having thread pool is faster. To fix Windows performance issues file had to be opened multiple times, once in each thread of the thread pool rather than once and shared with all threads by reference.

So not really a priority anymore for the use case I had.