Comment 1:

Brad, do you know off hand whether a remote size can distinguish between:
1. close socket fd, exit process
2. exit process
DIfferent error code from read on remote side?

Comment 2:

I don't know whether/when the Windows kernel sends a TCP RST packet when a process ends.
 If it ends with a normal exit status, the kernel should send normal shutdowns for all
of them (so it won't be any different)  If the process exits with an error, it might
send RST, but I doubt we care there.

Comment 3:

Brad, so don't think it's important to wait for outstanding read/write operations and
ensure that fd is closed before net.Conn.Close returns?
Currently unix impl allows both things (read/write operations happen after Close
returns, and fd is not closed after Close returns).

Comment 4:

Btw, Alex, the latter (fd is closed after Conn.Close returns) is not true on windows
either.
decref is dererred before read/write mutex unlock, so fd can be closed arbitrary time
after Conn.Close returns.

Comment 5:

Whatever the situation is, I think, it would be good if we can decide what is suppose to
happened and make sure it does happens.
Alex

Comment 6:

Agree. But the question is -- what is supposed to happen on close?
My fdMutex change unifies it to use unix behavior. If we don't know why we need to wait,
let't not wait.

Comment 7:

Owner changed to @dvyukov.

Status changed to Started.

Comment 8:

I am fine with "not waiting" on every OS. Until we find reason to do differently. "not
waiting" will probably make things feel *faster* then they really are.
Alex

Comment 9:

This issue was closed by revision 23e15f7.

Status changed to Fixed.