Open mei-rune opened 7 years ago
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.
I need run web app on the pipe.
Use some external library. Or write your own. It cannot be too complicated.
It provide a alternative package “gopkg.in/natefinch/npipe.v2”。 but it is unstable and low performance.
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 I don't have the ability to fix it ( “gopkg.in/natefinch/npipe.v2”).
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
I don't have the ability to fix it ( “gopkg.in/natefinch/npipe.v2”).
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
@techtonik 1. it is unstable. - https://github.com/natefinch/npipe/issues
Oh yea. golang
is extremely unstable then. =)
Do you have test for your issue? https://github.com/natefinch/npipe/pull/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 NPFS.sys
Named Pipes FileSystem built in to Windows that could be utilized to provide named pipes on WIndows... which I would like to know about.
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
go version
)? go version go1.7rc3 windows/amd64go 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=1On *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 https://github.com/golang/go/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.