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
Closed

net: keep SocketConn or not? #11492

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

Comments

@rsc
Copy link
Contributor

rsc 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
Copy link
Contributor

bradfitz 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
Copy link
Contributor Author

rsc 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
Copy link
Contributor

mikioh 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
Copy link
Contributor

bradfitz 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
Copy link

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.
Projects
None yet
Development

No branches or pull requests

4 participants