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

Re:\Device\Afd, or, the Deal with the Devil that makes async... by dblohm7 on Monday March 13, 2023 @06:51PM (#35144264)

Good god. I like nothing about this piece. I hate the claim that Windows networking is "duct-taped" in. I hate that they're using undocumented stuff. I hate that they're trying to shoehorn Windows into a Unix-y model; in my experience this is often symptomatic of failing to consider all platforms when originally designing the higher-level abstractions. Just blah.

> To make a long story that I don’t fully understand short, you need to have buffers that are pinned in memory and aren’t touched as long as the operation is in progress.

I don't understand why this is so confusing.

> I doubt that Microsoft is really rushing to make it so that you can’t run Javascript on Windows anymore.

Nah, but don't be surprised if suddenly a bunch of apps receive compatibility shims.

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by pornel on Monday March 13, 2023 @07:23PM (#35144693)

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?".

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by dblohm7 on Tuesday March 14, 2023 @02:07PM (#35155835)

That's how things have always been done at Mozilla (I spent several years there dealing with Windows-specific stuff for Firefox)... I kinda wonder if Rust inherited a lot of that attitude from there.

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by Dylan16807 on Tuesday March 14, 2023 @12:06AM (#35147326)

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

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

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by dblohm7 on Tuesday March 14, 2023 @02:13PM (#35155973)

That's fair, but how is that any different than async I/O on any other OS?

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by Dylan16807 on Tuesday March 14, 2023 @02:22PM (#35156139)

My understanding is the API they want notifies when data is ready, then you make a buffer and fill it immediately. In that situation a significantly smaller set of errors is possible and you don't have to figure out disposal of a pinned and possibly-in-use buffer if you decide to cancel.

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by fxtentacle on Tuesday March 14, 2023 @12:45AM (#35147553)

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.

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by dblohm7 on Tuesday March 14, 2023 @02:08PM (#35155855)

> 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.

Yup, you nailed it!

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by tiraniddo on Tuesday March 14, 2023 @07:41AM (#35149961)

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 ;)

[ Parent | on HN ]

Re:\Device\Afd, or, the Deal with the Devil that makes async... by dblohm7 on Tuesday March 14, 2023 @02:12PM (#35155950)

> 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.

Precisely. As somebody with extensive experience porting cross-platform applications to run on Windows, it smells more to me like "everybody involved in this is actually quite ignorant about Windows," instead of (what I am assuming is the intended) "look at this crazy shit we had to do because Windows sucks."

[ Parent | on HN ]