[ayanamist]

So linux people find that the model of windows iocp used is better?

[ot]

Yes, and now things are going full circle and windows is adopting the ring model too.

https://windows-internals.com/i-o-rings-when-one-i-o-operati...

[muststopmyths]

huh, interesting. As far as I can tell the main advantage this has over IOCP is that you can get one completion for multiple read requests.

Looks like they took a lot of the concepts from Winsock RIO and applied them to file I/O. Which is fascinating because with network traffic you can't predict packet boundaries and thus your I/O rate can be unpredictable. RIO helps you get the notification rate under control, which can help if your packet rate is very high.

With files, I would think you can control the rate at which you request data, as well as the memory you allocate for it.

The other thing it saves just like RIO is the overhead of locking/unlocking buffers by preregistering them. Is that the main reason for this API then ?

I would be very interested to hear from people who have actually run into limits with overlapped file reads and are therefore excited about IoRings

[hermanradtke]

As a Linux person: Yes, and I have thought so for a long time.

This is why many of us are excited about io_uring.

[asveikau]

I think it's long been understood that it's better for disk I/O. I'm not sure the consensus is as clear for sockets.

[volta83]

Yes.

Unfortunately Rust went the exact other way.

[spullara]

Now if they could allocate the memory for you when needed rather than having a bunch of buffers allocated when they aren't yet needed.

[lonjil]

That's what IOSQE_BUFFER_SELECT is for.

[spullara]

Awesome. I didn't see that when people were describing how it works. Certainly better than the Windows version.