This is my second merged contribution to rust-lang, and like the first it lives in the low-level I/O layer.
The problem
When a process runs out of file descriptors, the OS returns EMFILE (the per-process limit) or ENFILE (the system-wide one). Until recently, Rust's standard library decoded both into io::ErrorKind::Uncategorized. If you wanted to react to "too many open files" specifically, you couldn't match on the kind. You had to drop to the raw errno:
if err.raw_os_error() == Some(libc::EMFILE) {
// back off and retry
}
That works, but it leaks a platform detail into code that only wanted a category.
The fix
PR #158326 adds a dedicated variant to io::ErrorKind:
pub enum ErrorKind {
#[unstable(feature = "io_error_inprogress", issue = "130840")]
InProgress,
+ /// The process or the whole system has reached its limit on
+ /// the number of open files or sockets.
+ #[unstable(feature = "io_error_too_many_open_files", issue = "158319")]
+ TooManyOpenFiles,
+
// "Unusual" error kinds ...
Uncategorized,
}
and wires it into the per-platform decode tables, so both errnos map to it on unix and wasi:
libc::EMFILE | libc::ENFILE => TooManyOpenFiles,
with the matching ERROR_TOO_MANY_OPEN_FILES and WSAEMFILE on Windows. So now the category is first class:
match err.kind() {
io::ErrorKind::TooManyOpenFiles => back_off_and_retry(),
_ => return Err(err),
}
The variant is unstable for now (it implements ACP libs-team#818), behind #![feature(io_error_too_many_open_files)].
Why this corner
It is a small change, 13 lines. Reliability work usually is. This is the second PR I have landed in rust-lang's I/O code. The first documented the transient errors TcpListener::accept can hand you, the kind that are easy to treat as fatal by mistake. I am keeping at it on the low-level side, the layer the rest of the ecosystem stands on.
