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: UnixConn lacks CloseRead, CloseWrite #3345

Closed
remyoudompheng opened this issue Mar 18, 2012 · 11 comments

Comments

Projects
None yet
5 participants
@remyoudompheng
Copy link
Contributor

commented Mar 18, 2012

The net package lacks the ability to half-shutdown a Unix domain connection like it has
for TCP connections. This makes very hard to implement over Unix domain, protocols that
need client-side to send an EOF to the server.

I'd like to have

func (*net.UnixConn) CloseRead() error
func (*net.UnixConn) CloseWrite() error
@alberts

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

Comment 1:

TCP has it, so I'm guessing it could be added to UnixConn after Go 1.
http://code.google.com/p/go/source/detail?r=f68009c4a907
@alberts

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

Comment 2:

I've been playing with gob over unix sockets, and I don't always get an error in the
decoder if the remote end closes the socket after an encode error. Maybe it also has to
do CloseWrite (shutdown) before it closes?
@alberts

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

Comment 3:

Yep, just tested this. Should we try to sneak in another net CL? :-)
@alberts

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

Comment 4:

Here's an example app which behaves better if you have CloseWrite on the unix socket. I
just don't understand how it's supposed to work in the case where the remote end crashes
instead of shutting down cleanly.

Attachments:

  1. unix.go (2006 bytes)
@alberts

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

Comment 5:

I think there is a bigger problem. Here is a better test:
UnixPair sameProcClose closeWrite=false   hang
UnixPair sameProcClose closeWrite=true    ok
UnixPair childProcClose flag=panic        hang
UnixPair childProcClose flag=close        hang
UnixPair childProcClose flag=closeWrite   ok
UnixConnectedPair sameProcClose cw=false  ok
UnixConnectedPair sameProcClose cw=true   ok
UnixConnectedPair childProcClose panic    hang
UnixConnectedPair childProcClose close    hang
UnixConnectedPair childProcClose cw       ok
As I understand it, all of these should work.

Attachments:

  1. unix.go (3099 bytes)
@alberts

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

Comment 6:

Fixed up my unixPair function to close the output of os.NewFile after calling
net.FileConn, since it does a dup. A few more work now. Still investigating.

Attachments:

  1. unix.go (3432 bytes)
@alberts

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2012

Comment 7:

Okay, I fixed all the tests. So closing at least works to kill the connection, if you
make 100% sure you don't have extra file descriptors for it lying around in your process.

Attachments:

  1. unix.go (4403 bytes)
@dsymonds

This comment has been minimized.

Copy link
Member

commented Mar 18, 2012

Comment 8:

Labels changed: added priority-later, packagechange, removed priority-triage.

Status changed to Accepted.

@remyoudompheng

This comment has been minimized.

Copy link
Contributor Author

commented May 19, 2012

Comment 9:

Ping.
Would such a change be accepted for Go 1.1 or 1.x? Are there things to watch in
particular when it comes to Unix domain sockets specification?
@bradfitz

This comment has been minimized.

Copy link
Member

commented May 19, 2012

Comment 10:

Feel free to submit a patch.
@remyoudompheng

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2012

Comment 11:

This issue was closed by revision 0ce9045.

Status changed to Fixed.

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