-
Notifications
You must be signed in to change notification settings - Fork 608
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
Consistently connect to Unix sockets #2922
base: master
Are you sure you want to change the base?
Conversation
r? @nirs |
c1c8174
to
4bea537
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have to introduce a new netutil
package just for avoiding this single type assertion.
If you want to avoid a potential panic, you can just check conn, ok := unixConn.(*net.UnixConn); if !ok { return errors.New(...)}
Because this pattern occurs in a number of places (connecting to a UNIX socket, not the type assertion), this is reducing all that duplication.
I don't think a panic is a real concern. This is just cleanup. |
4bea537
to
5c4985e
Compare
@nirs this is what you wanted, no? |
I suggested to add a helper which would solve the issue for the vz package. The current change is little bit bigger and handle all unix sockets in lima (good), but it is hard to sell it as a way to avoid type assertions since we have only one. I did have time to review all the changes, but I think this will be easier to swallow if we change the commit/pr title/message to describe why creating unix socket in this way is better. |
net.UnixConn
type assertions5c4985e
to
b112727
Compare
Updated both the PR title and the commit message. |
Would appreciate a review here! |
The amount of the deduplicated code is trivial. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we remove the unneeded and possibly unwanted change to ignore the context in many places, the actual change is very small, maybe only in vz/network_darwin.go?
But since the change is so small, I'm not sure it worth the effort. The benefit is very small. Better to invest time on stuff that add more value.
90c60ea
to
5d68f9a
Compare
- Always use net.ResolveUnixAddr rather than constructing net.UnixAddr directly. - Use net.Dialer.DialContext in usernet. - Avoid type assertion on darwin. Signed-off-by: Tamir Duberstein <[email protected]>
5d68f9a
to
777ab85
Compare
See commit message.