@pmarks-net,

Sorry, I completely overlooked this case during the review.

This snippet fails in a similar way, using the go1.6 release:

package main

import (
        "log"
        "net"
        "time"
)

func main() {
        cancel := make(chan struct{})
        c, err := (&net.Dialer{Cancel: cancel}).Dial("tcp", "golang.org:80")
        if err != nil {
                log.Fatal(err)
        }
        close(cancel)
        defer c.Close()
        time.Sleep(3 * time.Second)
        req := []byte("GET /robots.txt HTTP/1.0\r\nHost: golang.org\r\n\r\n")
        if _, err := c.Write(req); err != nil {
                log.Fatal(err)
        }
        log.Println("done")
}

The Dialer documentation says:

// Cancel is an optional channel whose closure indicates that
// the dial should be canceled. 

I would interpret "the dial should be canceled" to mean that after Dial returns, closing the channel has no effect. Instead, it seems to travel back in time to kill the existing connection.

Was Cancel intended to apply just to the Dial operation, or to the entire lifetime of the connection?

I think both cases are slightly different. The former, which I mentioned, is just about how to handle the hidden channel for cancellation of multiple dial racers. The latter is for customer's dial cancellation.

Was Cancel intended to apply just to the Dial operation, or to the entire lifetime of the connection?

I believe the former.

I believe the former.

Then this is a pre-existing bug in dialTCP, which dialParallel is bringing to light. It's true that dialParallel cancels both racers, but only after one of them has successfully returned a connection.

So if cancelation were not retroactive, then dialParallel would work correctly.

So if cancelation were not retroactive

Yup, agreed.

I think the bug is here:
https://github.com/golang/go/blob/master/src/net/fd_unix.go#L108

The <-cancel and <-done cases are racing each other after connect returns. Instead, connect needs to wait for the goroutine to acknowledge the done event before returning.

CL https://golang.org/cl/21497 mentions this issue.