Pipe handle leaks when reconnecting

[mharbison72]

I noticed this using ProcessExplorer from Sysinternals on Windows, with this trivial program and v1.2.2:

func main() {
	if len(os.Args) == 2 {
		s, err := ipc.StartServer("sdtool_pipe", nil)
		if err != nil {
			fmt.Println(err)
			return
		}

		for {
			if msg, err := s.Read(); err != nil {
				fmt.Println(err)
				continue
			} else {
				fmt.Printf("CLIENT MSG: %+v\n", msg)
			}

			err = s.Write(1, []byte("PONG"))

			if err == nil {
				// handle error
				fmt.Println(err)
			}
		}
	} else {
		c, err := ipc.StartClient("sdtool_pipe", nil)
		if err != nil {
			fmt.Println(err)
			return
		}

		for i := 0; i < 10; i++ {
			message, err := c.Read() // client

			if err != nil {
				fmt.Println(err)
				continue
			}

			fmt.Printf("GOT MSG: %+v\n", message)
			// do something with the received messages

			err = c.Write(1, []byte("PING"))

			if err != nil {
				fmt.Println(err)
				continue
			}
		}
	}
}

Then, running app.exe serve only starts the server side, and lists two separate \Device\NamedPipe\sdtool_pipe entries in the open HANDLEs list of ProcessExplorer. I'm not sure why two, but that's not a big deal. Running app.exe will spin up a client to connect, and that adds another reference to the pipe in the server (which persists after the client exits). Running the client again will add a 4th reference, etc.

I suspect the problem is the server accept loop unconditionally overwriting the old connection with the new one:

golang-ipc/server_all.go

Line 70 in 71e822d

s.conn = conn

If I add a .Close() first, then the open file count rises to 3 for the first client run, but stays there for the second and further client runs (and I can see on old entry being cleaned up and a new one being added):

		if s.status == Listening || s.status == ReConnecting {

			if s.conn != nil {
				s.conn.Close()
			}

			s.conn = conn

I'm not sure if there's a way to get rid of the reference when the first client goes away, but wouldn't it be easier if the accept part was something the API user does, and that creates a separate object that manages each connection? That would seem to be the only way to handle multiple clients attempting to connect.