x/sys/windows: named pipes support on Windows #16655
Comments
|
Microsoft's implementation of named pipes for Go: https://github.com/Microsoft/go-winio |
|
As @alexbrainman said previously, this doesn't need to live in the standard library, since the standard library tries to just be portable stuff. I would normally suggest putting this in https://golang.org/x/sys/windows but if Microsoft already provides it at https://github.com/Microsoft/go-winio, I'd just use that, no? |
|
I agree with what Brad said. Not many people will use this functionality. And the approach is not portable to other OSes.
Use some external library. Or write your own. It cannot be too complicated.
You have source code for it. You can fix it. Or write your own. Or use Microsoft's implementation as suggested by @pi. (I never looked at either library, and I wouldn't know how good / bad they are). Alex |
|
@alexbrainman https://github.com/Microsoft/go-winio It looks like can be used, but I still want to put it in https://golang.org/x/sys/windows |
quentinmit
changed the title
I am sorry, but I don't have time to fix it either. Alex |
|
@runner-mei where is the upstream issue for that in https://github.com/natefinch/npipe/issues ? |
|
@techtonik 1. it is unstable. - https://github.com/natefinch/npipe/issues |
Oh yea.
Do you have test for your issue? natefinch/npipe#22 Or at least explanation of your commit? For example, I am not skilled to read where is the memory leak and how the code fixes it. Sometimes reviewing commits and writing tests for them takes much longer times than writing them. |
|
I will be forking npipe, because it looks like both it and Microsoft's "official" win-io package are getting approximately zero support. I need this capability for my own software. Stay tuned. |
|
There's also this Described well in: https://en.wikipedia.org/wiki/Named_pipe#In_Windows .NET Framework 3.5 or newer as well as MongoDB and some other tools can use them (so far.) There are also utilities for listing them: http://read.pudn.com/downloads8/sourcecode/windows/24726/pipelist.c__.htm |
gopherbot
added
the
compiler/runtime
go version)?go version go1.7rc3 windows/amd64
go env)?set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=d:\developing\go\xxx..\3td;d:\developing\go\meijing
set GORACE=
set GOROOT=d:\tools\go_amd64
set GOTOOLDIR=d:\tools\go_amd64\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\xxx\go-build491836642=/tmp/go-build -gno-record-gcc-switches
set CXX=g++
set CGO_ENABLED=1
On *nix we have unix sockets - a standard way of doing IPC (interprocess communication).
On windows we can use TCP sockets for doing the IPC, but a natural way of doing so according to this page (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx) is named pipes. Very close analogy to unix sockets. Providing net.NamedPipeConn in the net package sounds like a good idea to me. I need run web app on the pipe.
I find this issues #3599, but is closed. It provide a alternative package “gopkg.in/natefinch/npipe.v2”。 but it is unstable and low performance. All thread will blocked at syscall.WaitForSingleObject while Use PipeListener on the server.
The text was updated successfully, but these errors were encountered: