Stdin can block shutdown

[Darksonn]

Types such as Stdin and Stdout internally use blocking IO to read from the streams. This means that shutdown of the runtime can be blocked on threads with pending operations of this kind.

See #2318 as an example of when this happens.

[jakobrs]

Why doesn't tokio just epoll stdin directly in this case? stdin is a pipe and can therefore be used with epoll(7). Mio already supports this with mio::SourceFd, and tokio with tokio::io::unix::AsyncFd.

Here's the example in #2318, using tokio_fd::AsyncFd instead (which wraps tokio::io::unix::AsyncFd and implements AsyncRead and AsyncWrite):

use std::convert::TryFrom;

use tokio::io::AsyncReadExt;

#[tokio::main]
async fn main() {
    //let mut stdin = tokio::io::stdin(); // replaced with:
    let mut stdin = tokio_fd::AsyncFd::try_from(libc::STDIN_FILENO).unwrap();
    let mut buffer = [0; 8];

    let duration = std::time::Duration::from_secs(3);
    let timeout = tokio::time::sleep(duration);

    tokio::select! {
        _ = stdin.read(&mut buffer) => println!("reading done"),
        _ = timeout => println!("timeout!"),
    }

    println!("the end")
}

With this change the program no longer blocks when shutting down.

[sfackler]

1. stdin is sometimes a pipe.
2. Setting a pipe to nonblocking affects both ends of the pipe, so it's not really a thing you can do in the general case without breaking upstream and/or downstream processes in a pipeline.

[bnoordhuis]

It's not just pipes but e.g. ptys too.

I'd generalize it to the following observation: stdio file descriptors often exist in multiple non-cooperating processes. Changing the properties of a file descriptor in one process affects all other processes.

One linux-only workaround, at least for pipes, is to reopen the file descriptor through /proc/self/fd/<fd>.

For ptys, a workaround is to reopen /dev/pts/<fd> with the O_NOCTTY flag set if it's the slave/secondary. For master/primary ptys, blocking I/O is the only solution I'm aware of.