support for windows named pipes

[njsmith]

The subprocess PR (#791) added the core functionality to work with Windows named pipes, but only exposing in them in the limited case of talking to subprocesses. People may also want to use named pipes directly in some cases; they're kind of like windows's equivalent to AF_UNIX. (Well, except now AF_UNIX sockets are the equivalent to AF_UNIX sockets, but only on recent versions of Windows 10, so that won't be universally available for some time yet.) Perhaps we should have client and server helpers.

I was going to try to cite an example of a case where you have to use named pipes to connect to some program, but the only example I know is Discord and apparently they're using localhost sockets now? I know they used to, but I can't find any docs that mention named pipes anymore. So perhaps this is not a great argument for named pipe support being important.

There is also some question to figure out about how much of the named pipe API to expose – the full thing is somewhat complicated, with unidirectional/bidirectional streams, bytes vs. packets, peekable reads, etc., but I suppose just exposing a regular Stream-based APi would be a reasonable start

[njsmith]

One possible use case would be for setting up handles to talk to a child process, that aren't the standard 0, 1, 2 handles.

See https://github.com/python-trio/trio/issues/5#issuecomment-529272338

[njsmith]

Well, here's evidence that at least one person does want to use these: https://stackoverflow.com/questions/61519940/async-named-pipes-in-windows-using-trio-and-python/

[davidbrochart]

I think that this would be great to have. BTW why does this issue mention Windows only, since named pipes also exist on Unix?

[Sxderp]

BTW why does this issue mention Windows only

I think they're sufficiently different that they need to be handled separately.

Anyway, I ran into this as I wanted to port my MPV control program to Windows. MPV uses unix domain sockets on Linux and named pipes on Windows for IPC. I created a wrapper class that extends trio.abc.Stream for interacting with the pipe. I would not call it "production worthy" but it's enough of a toy example to work for me. Error handling is pretty poor. I wasn't sure how to determine if the other end finished so I just treat the broken pipe as "well that's the end."

I'm also not sure wtf wait_send_all_might_not_block is meant to do. I just left it unimplemented and things seem to work.

https://gist.github.com/Sxderp/cf797a1c1f510e0dfe1255c577fef74d