4 ms·

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 tha

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.

pornel 4y ago
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?".
- dblohm7 4y ago
  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.
Dylan16807 4y ago
> I don't understand why this is so confusing. Pinning a buffer is easy. Dealing with ownership ramifications in all situations is confusing.
- dblohm7 4y ago
  That's fair, but how is that any different than async I/O on any other OS?
  - Dylan16807 4y ago
    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.
fxtentacle 4y ago
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.
- dblohm7 4y ago
  > 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!
tiraniddo 4y ago
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 ;)
- dblohm7 4y ago
  > 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."

pornel 4y ago

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

dblohm7 4y ago
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.

Dylan16807 4y ago

> I don't understand why this is so confusing. Pinning a buffer is easy. Dealing with ownership ramifications in all situations is confusing.

dblohm7 4y ago
That's fair, but how is that any different than async I/O on any other OS?
- Dylan16807 4y ago
  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.

fxtentacle 4y ago

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.

dblohm7 4y ago
> 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!

tiraniddo 4y ago

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

dblohm7 4y ago
> 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."