Improve Mio windows support

[carllerche]

Mio is a low level abstraction on top of the operating system's evented I/O
APIs. It is used by Tokio to integrate with the operating system and perform the
I/O operations. The current Windows implementation is not ideal. A better
solution is outlined in
piscisaureus/wepoll.

Expected outcomes

The windows Mio implementation is rewritten using the strategy used by wepoll.

Skills

• Rust
• Windows networking

Difficulty level

Medium

[kingoftheconnors]

Hey! I'm interested in taking part in the project, but I'm not sure what is meant by "the strategy used by wepoll." Are you planning to build a custom version of the epoll API?

I'm also extremely new to rust. Do you know any good places I can go to to learn more about the language?

[arsing]

@kingoftheconnors Yes, wepoll exposes an epoll-like API (epoll_create1, epoll_ctl, epoll_wait) with some differences (SOCKETs instead of int fds, and some restrictions like no edge-triggered events).

I don't speak for mio/tokio, but I assume the expectation is to implement it in pure Rust and then use it in mio instead of libc::epoll_* for Windows targets.

That way a lot of the IOCP and buffer-pool related code inside mio::windows can go away. It should also allow for something like EventedSocket to be exported (like EventedFd is for Unix targets), which would make it easy for out-of-tree socket implementations like mio-uds to work with the "system" selector.

---

General info about wepoll:

wepoll works by opening a handle to the AFD device, then uses NtDeviceIoControlFile(IOCTL_AFD_POLL) to receive events for individual sockets. The ioctl is undocumented (*), so it has to define it and the associated structs and constants itself.

The ioctl is essentially how the (public) WSAPoll is implemented (which is presumably where piscisaureus reversed it from), but by using it directly with NtDeviceIoControlFile wepoll is able to receive the events in an overlapped fashion - all events are send to the IOCP associated with the AFD handle instead of blocking at a WSAPoll call. For each socket registered with the epoll handle, it uses the ioctl to associate the socket with the AFD device handle. Inside epoll_wait, for each event that it receives over the IOCP, it uses the ioctl to requeue the corresponding socket again.

The AFD poll events map reasonably closely to the epoll events, so the library is able to translate one set of events to the other.

(I found it easier to understand how it works by reading the dist file at https://github.com/piscisaureus/wepoll/blob/dist/wepoll.c compared to the split files in master, and following the call graph down from epoll_wait.)

(*) I brought this up with the Windows networking team, and they were quite surprised to learn that libuv has been using it since 2012. It is important to note that it is not a public API, so there is no guarantee that it will continue to work.

[TimonPost]

I'm interested in this subject too, I'm reading up on lots of sources related to this subject and mio. And hope to find some common ground for both Mio and wepoll. Is there any time estimation for this project?

[carllerche]

@TimonPost It is hard to really say how long as the answer will be very dependent on the student. However, it should take a minimum of a few weeks but be doable in a summer. The project is very "stretchy", so it should take up the entire summer :)

[TimonPost]

I came across those libraries, they are bindings for the wepoll library.
https://gitlab.com/yorickpeterse/wepoll-binding
https://gitlab.com/yorickpeterse/wepoll-sys

[PerfectLaugh]

I'm also interested in this subject too. I made a pull request about this.
tokio-rs/mio#868
But it is rather incomplete and hacky. The implementation needs a rewrite.