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: keep SocketConn or not? #11492

Closed
rsc opened this issue Jul 1, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@rsc
Copy link
Contributor

commented Jul 1, 2015

See CL https://go-review.googlesource.com/#/c/9275/.
Is this really necessary? I suspect not.

@rsc rsc self-assigned this Jul 1, 2015

@rsc rsc added this to the Go1.5 milestone Jul 1, 2015

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 1, 2015

I'm having a hard time understanding its docs:

SocketConn returns a copy of the network connection corresponding to the open file f and user-defined socket address sa. It is the caller's responsibility to close f when finished. Closing c does not affect f, and closing f does not affect c.

@mikioh, what does this enable users to do?

/cc @ianlancetaylor

@rsc

This comment has been minimized.

Copy link
Contributor Author

commented Jul 1, 2015

I intend to write a more complete comment on the CL but I have been preempted by other work.

As I understand it, SocketConn is FileConn but allows the use of arbitrary socket address types instead of just the few that FileConn knows about. It seems to me that the net package should just keep using (and providing) only FileConn but perhaps we can put a registration mechanism in package syscall to let clients register converters between sockaddrs and net.Addr for non-standard sockaddr types.

@mikioh

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2015

Thanks for the explanation, @rsc. Simply I wanted to allow us to mix features under the hood, various hardware-offloading stuff, new extensions for transport protocols and routing metrics for transport path selection, in existing network applications. For that purpose I needed to find out some way injecting unknown socket address and endpoint types in the standard library into runtime-integrated network poller.

perhaps we can put a registration mechanism in package syscall...

If it does make sense and is possible, I'm happy to revert the current change and will take the approach in Go 1.6.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 2, 2015

Yes, I'd prefer it be reverted for now too and we can give it more thought for Go 1.6.

@gopherbot

This comment has been minimized.

Copy link

commented Jul 2, 2015

CL https://golang.org/cl/11854 mentions this issue.

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.