Support fifo pipes on unix

[Darksonn]

Currently, we provide the UnixStream type for reading from a unix domain socket on Linux, but Linux also provides pipes. Domain sockets and pipes are not the same (see here). Furthermore, opening a named pipe with UnixStream::connect will fail with an error. Currently the only way to asynchronously read from a pipe is to use AsyncFd.

I would like to see a type in tokio::net for use with fifo pipes.

[satakuma]

I would like to work on this.

[Noah-Kennedy]

I'd be quite interested in this as well. @satakuma if you don't have the time for this LMK so I can jump in and help out.

[satakuma]

I investigated this subject a bit and here are my thoughts.

Proposed solution

Expose a new module tokio::net::pipe with Sender and Receiver types.

These types will be created using either a fn new() -> (Sender, Receiver) function (anonymous pipe) or methods Sender::open(path) and Receiver::open(path) to open a named pipe (FIFO).

Sender type should implement AsyncWrite and corresponding methods writable, try_writeetc., Receiver similarly should implement AsyncRead etc.

Motivation

• Mio already has relevant types which will facilitate the implementation.
• Since on a Unix system anonymous pipes and named pipes (FIFOs) are only different in the way they are created (pipe() syscall vs. mkfifo + open), tokio will be able to handle both cases with one set of types.
• Type system will prevent using pipes in the wrong direction, i.e. no writable method on the Receiver etc. Unlike bidirectional TcpStream and UnixStream, which can handle both reads and writes unless divided with the split method, a Unix pipe is unidirectional and therefore should have separate ends by default.

Non-blocking open

The Sender::open method using a non-blocking open syscall will succeed only if there already is an open reading end, and immediately fail otherwise. This means that there will be no way for a sender to asynchronously wait for a reader to connect besides blocking open syscall and spawn_blocking, which is not good.

On Linux, there is a workaround which opens the writing end with access to both read and write, but in general behavior of such operation is not defined. I guess the Sender type could have an additional method, for example Sender::open_dangling, which would allow opening a FIFO without waiting for a receiver, with a note warning about possible issues on other platforms.

Please let me know what you think @Darksonn and whether I should open a PR.

[Darksonn]

That sounds like a similar issue as the ERROR_PIPE_BUSY error on the Windows named pipe open method. For that method, we literally just recommend that you use a sleep loop to repeatedly try to open it.

We should simply provide the various methods that are possible, and then the user will just have to deal with the fact that Linux doesn't provide a good way to do this. It might be worth to include a method based on spawn_blocking, if it is the most reliable option.

The rest of your proposal sounds good.

[satakuma]

Support for FIFO pipes was added in #5351, closing.