| commit | b89e3bd662c27242909b446dbb80c74249fe6042 | [log] [tgz] |
|---|---|---|
| author | Carl Lerche <me@carllerche.com> | Tue May 14 21:01:20 2019 -0700 |
| committer | GitHub <noreply@github.com> | Tue May 14 21:01:20 2019 -0700 |
| tree | b5733cb17786b680e2229e1485bb71ae910e917e | |
| parent | 5e39b5836d04173b6f3e269a4e574398b1731179 [diff] |
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.
Mio is a lightweight I/O library for Rust with a focus on adding as little overhead as possible over the OS abstractions.
API documentation
This is a low level library, if you are looking for something easier to get started with, see Tokio.
To use mio, first add this to your Cargo.toml:
[dependencies] mio = "0.6"
Then, add this to your crate root:
extern crate mio;
The following are specifically omitted from Mio and are left to the user or higher-level libraries.
Currently supported platforms:
There are potentially others. If you find that Mio works on another platform, submit a PR to update the list!
A group of Mio users hang out in the #mio channel on the Mozilla IRC server (irc.mozilla.org). This can be a good place to go for questions.
Interested in getting involved? We would love to help you! For simple bug fixes, just submit a PR with the fix and we can discuss the fix directly in the PR. If the fix is more complex, start with an issue.
If you want to propose an API change, create an issue to start a discussion with the community. Also, feel free to talk with us in the IRC channel.
Finally, be kind. We support the Rust Code of Conduct.