Reconsider supported draining behaviour

[Thomasdezeeuw]

For Unix (kqueue and epoll) to drain readiness all you have to do is read/write until you get a "short" read/write, i.e. less bytes are processed than your buffer size. However Mio doesn't guarantee that another event is return until the I/O operations hits a WouldBlock error. This means that to strictly follow Mio's docs you'll have to issue another pointless system call (read/write/etc.).

This is because on Windows Mio could only guarantee the readiness to be drained once a WouldBlock error was returned. However nowadays we control that ourselves in IoSourceState::do_io. So, we could change it to reregister when e.g. the read bytes < buffer size.

Also find out if all of this is true for poll (see #1602).

[Janrupf]

Also find out if all of this is true for poll (see #1602).

If I understand correctly, it is. poll is level-based by default anyway, so we have full control over when we want to re-arm an edge trigger. #1602 currently does not implement this, but since for poll this solves other issues as well, I'm working on implementing edge-based triggers using IoSourceState.

[Noah-Kennedy]

This can be a pretty impactful optimization in certain workloads.

[Thomasdezeeuw]

One thing we need to consider are the try_io functions on various types, e.g. TcpStream::try_io, which currently don't give us access to the amount of bytes read.

[Thomasdezeeuw]

I don't think we can change the behaviour any more. The public try_io method doesn't have access to the internal success type of the function it's wrapping, nor could it know if e.g. a read was short. Furthermore I don't this working with the poll(2) implementation.

Based on that I'm going to close this and keep the current behaviour.

If someone does have an idea on how to support try_io and the poll(2) we can reopen this.

[utkarshgupta137]

Hi,

I'm building a server app that is mainly for use on Linux, but I want people to be able to run it on other OSs too for dev/testing etc. Currently, I'm doing that by maintaining separate code for epoll using nix & simple loop + poll every connection for other OSs. I want to use this crate to support kqueue/poll on other OSs, but I don't really care about 100% consistency between OSs.
I'm using epoll without EPOLLET currently, but there seems to be no way to disable this behavior when using mio. This makes it impossible for me to use this crate because level-triggered is just much better for my use case.
Would you accept a PR with a epoll-level feature or some other mechanism for supporting level-triggered mode for epoll (& as many other OSs) as possible? I understand that the whole point of this crate is to provide a consistent API across platforms, but this crate already supports OS-specific stuff using os-ext.

Thanks.

[Thomasdezeeuw]

@utkarshgupta137 Mio does care about cross OS consistency, for which we can't support different kind of triggers, we've tried in the past but it didn't work correctly across OS. At the moment I wouldn't consider something that wouldn't work at least on Linux, macOS and Windows.

[utkarshgupta137]

@Thomasdezeeuw According to the polling crate, iocp doesn't support edge-triggered mode? I've not read through the iocp code in mio, but surely this crate manages around that somehow?
My second point was that this crate already supports functionality that is exclusive to unix, so would it be too bad to add edge-triggered mode for epoll/kqueue?