Only emit UnixReady::hup() from kqueue when EVFILT_READ is set

[hawkw]

This branch changes the kqueue selector to only set the HUP bit for events whose filter type is EVFILT_READ. This is somewhat cargo-culted from how FreeBSD's Linux compatibility code translates kqueue events to epoll events. This appears to resolve tokio-rs/tokio#449.

I'll admit that I don't entirely trust this change. However, all of mio's tests pass with this change, as do all of tokio's when it depends on a version of mio with this patch. I haven't been able to come up with any other solutions to tokio-rs/tokio#449, so this is the best I've got so far. 🤷‍♀️

Signed-off-by: Eliza Weisman [email protected]

[asomers]

So what happens if a file descriptor EVFILT_WRITE and it gets HUPed? It looks like with this change, mio will set an error iff fflags != 0. Will that cause a write future to return with an error? I can see two ways for this to go wrong:

1. How can an application check for HUP without also trying to write to the file descriptor? (I don't even know how to express this with mio, even before your change).
2. What happens if a file descriptor gets HUPed but fflags == 0? It seems to me like mio would spin the cpu in that case, because the HUP condition would still be present when mio calls kevent again. I suspect that this won't happen for sockets, because you would've run across it already. But it might happen for named pipes, which use HUP a little bit differently than sockets.

[carllerche]

What are the next steps for this PR?

[hawkw]

@carllerche

What are the next steps for this PR?

Honestly, I'm not sure. I don't know if this is a viable solution given @asomers' questions and my own concerns, but I don't currently have a deep enough understanding of the problem to determine what a better solution might be.

[Thomasdezeeuw]

I think the if statement should be removed and hup should always be set if EV_EOF is set. From the FreeBSD kqueue manual [1]:

EVFILT_READ:
If the read direction of the socket has shutdown, then the filter also sets EV_EOF in flags, and returns the socket error (if any) in fflags.

EVFILT_WRITE:
The filter will set EV_EOF when the reader disconnects [...]

The way I read that is if either you can't read anymore (read direction was shutdown), or you can't write anymore (reader was disconnected) it sets the EV_EOF flag. The best way we can relay that information currently is via hup readiness.

[carllerche]

#939 should cover this. Thanks for the initial work 👍