-
Notifications
You must be signed in to change notification settings - Fork 18k
net: can {Conn,PacketConn}.Close block? #18187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
For reasons that I don't understand, I'm not able to get In other implementations I'm looking at, it is impossible to get |
#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
|
@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 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? |
Does it still need to update the document? |
Change https://go.dev/cl/655517 mentions this issue: |
The documentation for
net.Conn.Close
is:However, it does not mention anything about whether
Close
itself can block.Some
net.Conn
implementations have an implicit write buffer. Thus, whenClose
is called, it still needs to flush the buffer before returning. This means thatClose
is effectively an operation that involves IO. Since it involves IO, this means thatClose
may have to wait until the recipient acknowledges the incoming data (which could potentially be forever if the receiver's read buffer is full).If we extend the documentation for
net.Conn.Close
, would the following be reasonable?\cc @bradfitz @mikioh
The text was updated successfully, but these errors were encountered: