Introduce AsyncHandle - a Windows version of AsyncFd

[udoprog]

Unix systems have access to AsyncFd, an abstraction which allows for wrapping custom file descriptors supporting nonblocking I/O so that it can be used in an asynchronous context. We don't have an option like that in Windows. Instead wrappers have to be introduced for custom types, usually all the way from miow, mio and then tokio (using named pipes as an example).

This can't be immediately introduced, because implementing support for a custom handle in mio currently requires access to mio internals. Both due to how overlapped I/O works (requiring ownership of buffers used in it) and how it is integrated in mio. Furthermore mio is not stable, so Tokio can't directly expose anything from it until it is due to its stability guarantees.

Consequently there's a fair bit of design work that needs to happen all across the stack. This issue is opened to keep track of this, and be a hub to discuss it.

Links:

• Relevant issue in mio

Comments about it:

• Comment by @ColinFinck

[notgull]

What kind of work is left here to do? This would be very useful to me, as I would like to be able to wrap a breadx::Display in an AsyncHandle on Windows in order to avoid having to define entirely different types to work with async.

[Darksonn]

I believe the major issue is determining what the API surface should be. We don't want to stabilize something that only works for a few kinds of handles, or which has other challenges. I simply don't understand handles well enough to tell whether any given proposal for an API surface is appropriate.

[notgull]

Would an AsyncSocket be an adequate replacement? Sockets are a subset of Handles (IIRC), and behave in more similar ways to each other than Handles do.

[Darksonn]

It could be, but I don't know enough about it to say.