AF_UNIX is supported on Windows now, and has some advantages over named pipes:
https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
What are your thoughts on adding support for this to the uv_pipe_* family of functions?
UV_NAMED_PIPE already means "named pipe" on Windows and "unix socket" on Unix, maybe a new UV_UNIX_SOCKET flag could be used to opt-into AF_UNIX behavior on Windows?AF_UNIX is supported, UV_NAMED_PIPE could use AF_UNIX unconditionally. But this could break applications that assume pipe names have \\.\pipe\... format.I think something along the lines of 1) would be best. We have uv_pipe_init_ex which. takes a flags argument so there is a place where this could be turned on.
I think the main challenge/question would be that the uv_pipe_* code currently expects to operate on a windows HANDLE object, whereas this would be a SOCKET object. So should this fall more under uv_tcp or uv_pipe? I expect it would share most of its code with uv_tcp and little with uv_pipe. On Unix, UV_NAMED_PIPE presently means {"pipe" or "fifo" or "unix socket"}. We could perhaps move the "unix socket" capabilities into the existing libuv stream socket representation (aka uv_tcp) though, which might be more cross-platform stable (due to somewhat better alignment with the underlying system APIs everywhere).
Aside: for anonymous local sockets (e.g. not with connect/bind on filesystem paths), in https://github.com/libuv/libuv/pull/1498, I am adding uv_socketpair for making local socket pairs.
That's kinda what Unix does with having most of the stuff in stream.c, right? Makes sense to do the same here IMHO.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This stale bot is obnoxious. What is the point of closing old issues just because no one addressed them ?
Most helpful comment
This stale bot is obnoxious. What is the point of closing old issues just because no one addressed them ?