tree b5733cb17786b680e2229e1485bb71ae910e917e
parent 5e39b5836d04173b6f3e269a4e574398b1731179
author Carl Lerche <me@carllerche.com> 1557892880 -0700
committer GitHub <noreply@github.com> 1557892880 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJc248QCRBK7hj4Ov3rIwAAdHIIABJtrlf9JkozVdSdOq+xhD/2
 XVQ/nI8692g3Jitp5Yasrp0Cqn6xv8I5sb0elA8hCgjOV5e5W4I/kAVt7WSvclYx
 VchwDIOu2wd8RXp2NJrFePTJjkvNA1PlPOHhQsHAyy4WqHLPO0qcoJjhucySXjEC
 F0WAyjuNpwgoHHhNbmnQeJ/N6O1mm+je8jhZpXUxBrmH+lBsyRG1WRdaEO0OmDQd
 3Snf2pANh2v+uMiYTQzL8EbPZmJpqqHQYwSnenXRIAi16fmC3V2btSg/CVcRqLih
 RyAJ4hFIPjKm6fGqUggdS5GvgE2t6dLgB8t644iW+BmhKk4AQOrjauhyO3RAbWk=
 =OdTT
 -----END PGP SIGNATURE-----
 

Don't report `RDHUP` as `HUP` (#939)

Currently, EPOLLRDHUP sets UnixReady::hup(). This is incorrect behavior
because higher-level libraries like tokio (correctly) assume that
UnixReady::hup() is unclearable since it signals that both the read and
write halfs are shutdown. In reality, EPOLLRDHUP only means that the TCP
stream has been half-closed and such a half-closed stream can still be
written to.

This will fix a current issue with tokio, which is that tokio infinitely
attempts to write to a half-closed socket that's returning WouldBlock
when it's write buffer is full, an issue which manifests with excessive
CPU usage. I think this may help some of the issues discussed in
tokio-rs/tokio#449

After this change, EOF will still be propagated correctly, because
read-hangups also trigger read-readiness via EPOLLIN. However, if
handling of EPOLLRDHUP is desired to be retained, I believe it should be
implemented as another readiness kind on UnixReady, perhaps
UnixReady::read_hup().

Possible concern of a breaking change: Since it's not currently possible
for a user of mio to differentiate between EPOLLHUP and EPOLLRDHUP, it
must be that no users of mio currently are. There _may_ be applications
that test the "health" of a socket by checking for UnixRead::hup(),
which would previously trigger on EPOLLRDHUP but will no longer with
this change. This will change such applications from considering a
half-closed connection as closed to considering it open. However, I
still beleive this change is a correction of the semantics of HUP and
the desired behavior such applications was already ambiguous.

This also fixes a similar issue with kqueue.