calls to this for purposes of retrieving auto-assigned port numbers are necessarily made from a separate goroutine than the one that called ForwardPorts() (since that method blocks until the operation is complete). That means that anything using the value returned from this method is subject to data races with the port.Local = uint16(localPortUInt) assignment.

At the very least, we need to protect against that data race.

A bigger question is whether this method should block until the ForwardPorts() call has established listeners and the actual local ports are available.

Originally I was going to leave it up to the caller to avoid the race, since any user of this would also have to know about Ready, and once Ready is signaled, the local ports are available, too. I perhaps should have documented that in the func doc.

(This code is meant specifically to close races like this.)

If you prefer, though, I can move the exclusion to here, no big deal. My first inclination would perhaps to be something like

	close(pf.listenersReady)
	if pf.Ready != nil {
		close(pf.Ready)
	}
...
func (pf *PortForwarder) GetPorts() ([]ForwardedPort, error) {
	select {
	case <-pf.listenersReady:
		return pf.ports, nil
	default:
		return nil, fmt.Errorf("listeners not ready")
	}
}

A caller would already be doing its own blocking on the Ready channel (if they cared to) so leaving GetPorts nonblocking seems fine, but I'll defer toYourJudgement() on that (obviously, not a huge code change either way). :)

or, could require a Ready channel be specified in order to use GetPorts() (which they have to provide if they want to call GetPorts() safely)... what do you think of something like this:

func (pf *PortForwarder) GetPorts() ([]ForwardedPort, error) {
	if pf.Ready == nil {
		return nil, fmt.Errorf("no Ready channel provided")
	}
	select {
	case <-pf.Ready:
		return pf.ports, nil
	default:
		return nil, fmt.Errorf("listeners not ready")
	}
}

SGTM. Updated the PR.