Currently AnonymousPipeServerStream and AnonymousPipeClientStream on Unix are implemented on top of pipe. This makes sense, but it also makes it difficult for us with our current infrastructure to properly implement async I/O for these streams. This means that Read/WriteAsync on these types are actually async-over-sync and also that cancellation only ends up doing an up-front check and doesn't actually support canceling an operation in progress.

NamedPipeServerStream and NamedPipeClientStream on Unix are instead implemented on top of unix domain sockets via System.Net.Socket, and that implementation makes it possible to just rely on the built-in async and cancellation support Socket provides. We could do the same thing with anonymous pipes, using socketpair instead of pipe to create the underlying file descriptors, and then wrapping those with Socket just as we do in the named pipes.

@tmds, thoughts on this? There would likely be some subtle differences in behavior, especially around buffering. I'm wondering as well if it might be visible in a bad way for anyone extracting the file descriptor from the SafeHandle and using it in some way that pipe-generated file descriptors would work but socketpair-generated file descriptors wouldn't.