Consider implementing AnonymousPipeServer/ClientStream on Unix on socketpair

[stephentoub]

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.

[tmds]

If the AnonymousPipeClientStream is constructed from a handle that is a pipe (because the peer is not a .NET 6+ app) it will give issues when we treat it as a Socket. Socket specific APIs will return ENOTSOCK.

We could try make Socket more pipe friendly by using calls like read/write instead of recvmsg/sendmsg. Then the handle can remain a pipe and we can still leverage the SocketAsyncEngine.

[stephentoub]

If the AnonymousPipeClientStream is constructed from a handle that is a pipe (because the peer is not a .NET 6+ app) it will give issues when we treat it as a Socket. Socket specific APIs will return ENOTSOCK.

Good point. We could allow APCS to support both; you just wouldn't get the benefits in the case where it was pipe.

We could try make Socket more pipe friendly by using calls like read/write instead of recvmsg/sendmsg.

Would that have any negative throughput implications for Socket?

Then the handle can remain a pipe and we can still leverage the SocketAsyncEngine.

I don't want multiple instances of the SocketAsyncEngine in play, so we would need to expose it in some way for the other assembly to use. This gets back then to how do we push that infrastructure lower for any assembly to use. If you have ideas for what that looks like, I'd love to hear them. We've talked at a high-level about building this support into ThreadPool, and having some kind of API on ThreadPool that sits on top of this. If you have the time and inclination, that could be really interesting to experiment with and come up with a proposal for. Our async I/O support on unix outside of Socket today is lacking.

[tmds]

With #44647 AnonymousPipeServer/ClientStream use SocketAsyncEngine. This issue may be closed.

[manandre]

@tmds With #44647 NamedPipeServer/ClientStream seem to also use SocketAsyncEngine. Can the related issue #44331 be closed?

[stephentoub]

Yup.