On Mon, Mar 25, 2019 at 11:04 AM Matt Layher <mdlay...@gmail.com> wrote: > > 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!
If you are only calling File so that you can change properties of the descriptor, then I agree that you always use SyscallConn instead. But if you are calling File just to pass a socket to something that expects a *os.File, then it remains useful. I don't think I would call it deprecated, though we could consider removing it if we ever make a net/v2 package. Ian -- 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.
