Skip to content
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: unix/windows handling of netFD.Close is different #6074

Closed
dvyukov opened this issue Aug 7, 2013 · 9 comments

Comments

Projects
None yet
5 participants
@dvyukov
Copy link
Member

commented Aug 7, 2013

> Comment #9 on issue #5792 by alex.brainman: net/rpc: data race on non-net
> transport
> https://golang.org/issue/5792
>
> Dmitriy,
>
> While we're on this subject, I would like to talk to you about
> (*netFD).Close. I could be wrong, but, I think, semantically windows and
> unix (*netFD).Close are different. One waits for all outstanding IO to
> finish, while the other does not. The questions here is: "What is guaranteed
> on (*netFD).Close return? Can it be assumed that all outstanding IO is
> completed and is flushed to OS or canceled? Can we be certain that OS socket
> is closed?". Perhaps it is not important, but I would like to run this
> concern by you.
>
> Alex
@dvyukov

This comment has been minimized.

Copy link
Member Author

commented Aug 7, 2013

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?
@bradfitz

This comment has been minimized.

Copy link
Member

commented Aug 7, 2013

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.
@dvyukov

This comment has been minimized.

Copy link
Member Author

commented Aug 7, 2013

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).
@dvyukov

This comment has been minimized.

Copy link
Member Author

commented Aug 7, 2013

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.
@alexbrainman

This comment has been minimized.

Copy link
Member

commented Aug 7, 2013

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
@dvyukov

This comment has been minimized.

Copy link
Member Author

commented Aug 8, 2013

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.
@dvyukov

This comment has been minimized.

Copy link
Member Author

commented Aug 8, 2013

Comment 7:

Owner changed to @dvyukov.

Status changed to Started.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Aug 8, 2013

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
@dvyukov

This comment has been minimized.

Copy link
Member Author

commented Aug 9, 2013

Comment 9:

This issue was closed by revision 23e15f7.

Status changed to Fixed.

@dvyukov dvyukov added fixed labels Aug 9, 2013

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015

@rsc rsc removed the go1.2maybe label Apr 14, 2015

@golang golang locked and limited conversation to collaborators Jun 24, 2016

This issue was closed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.