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.