The catch here is that Go RPC server continuously polls for new requests (has a blocking read going on), even while a request is running (and a reply is written back to the pipe). There are two reasons why this does not work out of the box:

1. The current os.File implementation uses a Mutex to protect the file offset it is writing to / reading from, so if a blocking Read is going on, it will keep the mutex locked.
2. Windows cannot read and write to the same file handle concurrently unless overlapped I/O is used.

Also, there is the minor issue that any broken pipe error is silently being eaten by os.File.Read().

My patch switches npipe to use ReadFile and WriteFile instead of os.File, passing an Overlapped structure to do overlapped I/O. I've also added a new test case TestGoRPC() to test Go RPC over the named pipe implementation.

When a client connects to a server and immediately disconnects, accept will return with an error_no_data, which is inconsistent with the behavior of other go Listeners. This patch will make Accept() ignore error_no_data, since there is nothing to do in that case anyway.

Hello,

This builds and runs well on Windows 10 but produces an error on any linux install:

johnnyb@tasha:~/Projects/named/client$ go build
# _/home/johnnyb/Projects/named/client
./client.go:12:15: undefined: npipe.Dial
johnnyb@tasha:~/Projects/named/client$ cat -n client.go
     1  package main
     2
     3  import (
     4          "bufio"
     5          "fmt"
     6
     7          "gopkg.in/natefinch/npipe.v2"
     8  )
     9
    10  // Use Dial to connect to a server and read messages from it.
    11  func main() {
    12          conn, err := npipe.Dial(`\\.\pipe\mypipe`)
    13          if err != nil {
    14                  // handle error
    15          }
    16          if _, err := fmt.Fprintln(conn, "Hi server!"); err != nil {
    17                  // handle error
    18          }
    19          r := bufio.NewReader(conn)
    20          msg, err := r.ReadString('\n')
    21          if err != nil {
    22                  // handle eror
    23          }
    24          fmt.Println(msg)
    25  }

Is this expected? Since it' pure Go I was hoping it would work on both OS's. I do a fair amount of Go building on both platforms so the linux Go env is sane.

Thanks!

JB

There's a race condition in which PipeListener.Accept and PipeListener.Close are called from separate goroutines. Either method can mutate the state of the PipeListener (l.closed, l.handler). These sections need to be protected with a mutex.

There was an obvious race between PipeListener's Accept and Close modifying l.closed, found with go test -race, and a less obvious race that if someone calls Close before we call connectnamedpipe, the connect would hang forever. Now we have a lock over the whole of Accept and Close (except while doing WaitSingleObject, which will corrently return an error when we Close), so Close can't screw up connect named pipe.

Depends on #17. This fixes all the go test -race ./... errors in the v2 branch, but TestGoRPC still randomly hangs on waitForCompletion -- which tells me there's possibly still an issue with concurrent goroutines in Accept() and Close().

@natefinch @gabriel-samfira Any ideas?

Hi,

My requirement is to connect to server. Send the some data in structure. Server will update the signature and send back to client(i am client) as structure. Server is in c++ and they used piped for connection.

if _, err := fmt.Fprintln(conn, dat); err != nil { //error } by using this i can send the structure value or map.

But how can I receive the value in structure from server? Please guide.

The overlapped.HEvent has been closed in PipeListener.Close and reset to 0. But close again in PipeListener.AcceptPipe with origin HEvent. So that throw a panic which cannot be recovered.

The overlapped.HEvent has been closed in PipeListener.Close and reset to 0. But close again in PipeListener.AcceptPipe with origin HEvent. So that throw a panic which cannot be recovered.