I've been doing low-level networking work in Go for a few years now, but I had a realization the other day:
With the addition of the SyscallConn method in Go 1.9 to several net.Conn/PacketConn types, what is the advantage of using the File method at this point in time? The documentation (https://golang.org/pkg/net/#IPConn.File) mentions: > File returns a copy of the underlying os.File It is the caller's responsibility to close f when finished. Closing c does not affect f, and closing f does not affect c. > > The returned os.File's file descriptor is different from the connection's. Attempting to change properties of the original using this duplicate may or may not have the desired effect. But the syscall.RawConn provides a handle to a non-dup'd file descriptor, which can be used for dealing with socket options and runtime network poller-integrated reads/writes. To my knowledge, changing the properties of the file descriptor passed in syscall.RawConn methods will always have the desired effect, because it offers direct access to the file descriptor. Which leads to my next question: if SyscallConn provides better flexibility, is it time to add a deprecation notice to the File method on various package net types, in favor of SyscallConn? Perhaps there's some benefit to File that I'm not seeing. If so, I'd be curious to find out! Thanks, Matt Layher (@mdlayher) -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
