For reasons that I don't understand, I'm not able to get TCPConn.Close to block even when I write as much data on one endpoint while nothing is reading on the other endpoint.

In other implementations I'm looking at, it is impossible to get Close to be non-blocking since the underlying layers provide no control over flushing and have implicit write buffers built into them.

#10527 is for Listener.Close.

Yes, we've had to make changes to the net/http package in the past due to net.Conn implementations blocking on Close. If it's an interface, anything can happen. It's fine to document that it may block, if it's not overly wordy.

Is it possible or not that a TCPConn.Close() may block?

Scenario:

I have a "high concurrency" client on a payment processing solution under production which when it detects the connection might be dead (multiple concurrent errors on non blocking read() or write() calls) it enters a reconnect loop to different secondary backup servers until it gets able to keep processing transactions.

A couple of days ago the single threaded component handling de TCP socket I/O hanged out, watching the source code for hours i couldn't find a single blocking condition, suddenly i realized, might be Close() blocking?

Why i perform the Close call? because the underlying protocol (old credit cards processing protocol implementation) would send back responses on any opened detected socket, no matter in which socket it received the request.. so if i don't perform the correct TCP connection closure before establishing a new TCP connection i might get into an scenario were the responses for the requests sent through the new established socket might start getting back in the original connection once the networking issue gets solved.

So, the question made by @dunjut is really critical in my scenario. Is Close() candidate to block? I was really not expecting this condition to happen :(

You can have a blocking conn.Close by doing something like:

...
reader := bufio.NewReader(conn)
go io.ReadFull(reader, buf)
conn.Close()

@dsnet Did you create a PR for it?

That's it, I call it a day. Can we fix it?

I finally solved it, thanks to https://stackoverflow.com/questions/28967701/golang-tcp-socket-cant-close-after-get-file, call conn.CloseRead() before calling conn.Close().

func Close(conn io.Closer) error {
	type ReadCloser interface {
		CloseRead() error
	}
	var errs []error
	if closer, ok := conn.(ReadCloser); ok {
		errs = append(errs, closer.CloseRead())
	}
	errs = append(errs, conn.Close())
	for _, err := range errs {
		if err != nil {
			return err
		}
	}
	return nil
}

Can this issue be closed?