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

net: can {Conn,PacketConn}.Close block? #18187

Open
dsnet opened this Issue Dec 3, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@dsnet
Member

dsnet commented Dec 3, 2016

The documentation for net.Conn.Close is:

Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors.

However, it does not mention anything about whether Close itself can block.

Some net.Conn implementations have an implicit write buffer. Thus, when Close is called, it still needs to flush the buffer before returning. This means that Close is effectively an operation that involves IO. Since it involves IO, this means that Close 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?

Close closes the connection. Any blocked Read or Write operations will be unblocked and return errors. Close itself may block while it is flushing any internal write buffers, but must return an error and terminate the connection when a previously set write deadline is exceeded.

\cc @bradfitz @mikioh

@dsnet dsnet added this to the Go1.8 milestone Dec 3, 2016

@dsnet

This comment has been minimized.

Member

dsnet commented Dec 3, 2016

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.

@mikioh mikioh changed the title from net: can Conn.Close block? to net: can {Conn,PacketConn}.Close block? Dec 4, 2016

@mikioh

This comment has been minimized.

Contributor

mikioh commented Dec 4, 2016

#10527 is for Listener.Close.

@bradfitz

This comment has been minimized.

Member

bradfitz commented Dec 4, 2016

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.

@bradfitz bradfitz added NeedsFix and removed NeedsDecision labels Dec 4, 2016

@bradfitz bradfitz modified the milestones: Go1.9Maybe, Go1.8, Go1.8Maybe Dec 5, 2016

@bradfitz bradfitz modified the milestones: Go1.9, Go1.8Maybe Dec 15, 2016

@bradfitz bradfitz modified the milestones: Go1.10, Go1.9 Jun 26, 2017

@dsnet dsnet modified the milestones: Go1.10, Unplanned Nov 10, 2017

@dsnet dsnet removed their assignment Dec 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment