code review 5491044: net: expose the underlying network file descripor of th...

net: expose the underlying network file descripor of the Conn

New struct ConnFD represents the underlying network file descriptor
for bridging between net package and other packages which may want
to control IPv4, IPv6 layer control plane stuff by using IPPROTO_IP,
IPPROTO_IPV6 level socket options.

Also added ConnFD method to TCPConn, UDPConn, IPConn and SysFD method
to ConnFD.

[mikio, 2011-12-15 05:02:13]

Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://go.googlecode.com/hg/

[mikio, 2011-12-15 05:56:34]

On Thu, Dec 15, 2011 at 2:02 PM,  <mikioh.mikioh@gmail.com> wrote:

> New struct ConnFD reprents the underlying network file descriptor
> for bridging between net package and other packages which may want
> to control IPv4, IPv6 layer control plane stuff by using IPPROTO_IP,
> IPPROTO_IPV6 level socket options.

Er, I don't intend to populate the socket descriptor or socket
control ops everywhere. I'd like to add a few packages like
<http://codereview.appspot.com/5489045/> to Go 1.1 and
beyond.

[albert.strasheim, 2011-12-15 06:37:52]

On 2011/12/15 05:02:13, mikioh wrote:
> Hello mailto:golang-dev@googlegroups.com,
> 
> I'd like you to review this change to
> https://go.googlecode.com/hg/

Very nice. This will allow us to address the Setsockopt stuff in

http://codereview.appspot.com/5487075/

in our own code until there is a proper API for it.

An alternative would be Fd()int for UNIX sockets and Fd()syscall.Handle for
Windows. Is it worth hiding this detail inside ConnFD?

Another minor nitpick: os.File has a function called Fd(), but I see the net
package has an internal struct called netFD, which lead to ConnFD instead of
ConnFd. But maybe that's the way it is...

[mikio, 2011-12-15 07:05:16]

On Thu, Dec 15, 2011 at 3:37 PM,  <fullung@gmail.com> wrote:

> An alternative would be Fd()int for UNIX sockets and Fd()syscall.Handle
> for Windows. Is it worth hiding this detail inside ConnFD?

I haven't had much experiences on Windows, honestly speaking,
it's just insurance.

> Another minor nitpick: os.File has a function called Fd(), but I see the
> net package has an internal struct called netFD, which lead to ConnFD
> instead of ConnFd. But maybe that's the way it is...

ConnFd() or ConnFD(), I have no concrete opinion.
Please let me know which is better, consistent one.

[rsc, 2011-12-15 16:52:04]

If this were going to go in, it should be like in os:
Fd() int on Unix and Fd() syscall.Handle on Windows.

However, I am very hesitant to put this in at all.
It will be a crutch that will keep us from defining
a portable net API.  The reason this came up most
recently was for SO_REUSEADDR on Windows
but we found that the net package was just doing
the wrong thing there and I believe that is being fixed.

If the fd is exposed, all attempts at making something
that works everywhere are going to stop.  Or at least
I'm afraid of that being true.

Russ

[bradfitz, 2011-12-15 17:44:54]

I agree with the fear.

I also fear that it'll lead to weird bug reports where people messed with
the fd somehow and Go's net package / epoll still think they own it,
leading to conflicts.

On Thu, Dec 15, 2011 at 8:52 AM, Russ Cox <rsc@golang.org> wrote:

> If this were going to go in, it should be like in os:
> Fd() int on Unix and Fd() syscall.Handle on Windows.
>
> However, I am very hesitant to put this in at all.
> It will be a crutch that will keep us from defining
> a portable net API.  The reason this came up most
> recently was for SO_REUSEADDR on Windows
> but we found that the net package was just doing
> the wrong thing there and I believe that is being fixed.
>
> If the fd is exposed, all attempts at making something
> that works everywhere are going to stop.  Or at least
> I'm afraid of that being true.
>
> Russ
>

[mikio, 2011-12-16 00:26:37]

*** Abandoned ***