\Device\Afd, or, the Deal with the Devil that makes async Rust work on Windows

Rust sometimes is very Linux-centric. This problem has been considered when async was in the draft stage, and shrugged off, because it's just Windows. macOS in Rust is also treated as "it's just a weird Linux, right?".

> I don't understand why this is so confusing.

Pinning a buffer is easy. Dealing with ownership ramifications in all situations is confusing.

I belive the issue here is that the author very much likes Rust and is not willing to openly admit that Rust's needs Windows-specific features.

I found it odd that even the examples for low-level C APIs were presented through Rust wrappers.

"the overarching idea is that IOCP doesn’t gel well with not only the Future model, but also with Rust’s borrow checker as a whole" comes pretty close, though, but it's still lacking the insight that it's an issue in Rust's language design and not in Windows.

Also, I've heard a lot of praise about Microsoft's networking integration which made things like mounting network drives possible and reliable as early as Windows 2000. But of course, if you refuse to use the recommended APIs, you'll suffer for it.

I wonder if the author would describe it in similar detail, if they open a Linux device like /dev/video0 and send a V4L syscall to it. Because that's the equivalent to using the Afd device.

That said, I enjoyed their word choices and writing style.

The article also felt like Rust does it this way because all these other projects which came before it did it this way. Someone originated the technique and no one questions its validity, without seeing if there was an alternative method to achieve the same result.

I did spend about 20 minutes looking into this, it seems that there's an (admittedly undocumented) IOCTL which is in the Winsock headers (MSWsock.h) called SIO_EXT_POLL which seems to just use the poll device IO control code and so they could probably do this without messing with low-level AFD weirdness.

That said you'd think with Microsoft going all in on Rust, last I heard at least, that they could find a way to re-implement this code correctly. Hell, if they at least documented the IOCTL they could probably get co-pilot to do it for them ;)

I can name a few through my journeys.

Perl is a temple. You construct some ritualistic temple of a project, leave it be for years and will stand happily without any issues. Come back many months later, add a single comment; total Indiana Jones scenario.

TCL is voodoo, it does stuff that shouldn't work but does awesomely. How it does it is just voodoo.

Ruby is just magic. You create a thing, change one thing and the next thing you know you've suddenly got two features for the price of one.

PHP is a sheep.

Windows does offer an official API for this, as the article states. Unfortunately, everyone wants an API that works exactly like epoll, and IOCP just Doesn't Work Like That. It's actually way closer to how most people would expect async I/O to work, were they to design it from scratch without the well being poisoned by knowledge of epoll.

However, every *nix / macOS person writes their epoll code, then finds out that it Doesn't Work That Way on Windows, so this gives them back their epoll-like API.

From a Windows development point of view, Linux is way behind. Async I/O has been at the core of the NT kernel since the very beginning (since VMS, even), whereas on Linux (and Unix) everything has been designed with blocking I/O in mind. IOCP match the way people usually think about asynchronous processing, but people have just become used to the weird way poll and epoll do things. It's like saying Windows is behind Linux because it doesn't support Unix permissions.