Re: [go-nuts] net.Conn types: File vs SyscallConn method
On Mon, Mar 25, 2019 at 11:04 AM Matt Layher 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.
Re: [go-nuts] net.Conn types: File vs SyscallConn method
From the docs in syscall:// Conn is implemented by some types in the net and os packages to provide 30 // access to the underlying file descriptor or handle.Note, the "some" - meaning it is an optional interface, most likely in the os packages. I've always understood the syscall package to be implementation specific, and with no guarantees - where as the net package is higher level abstraction and is cross platform.The File abstraction works because a File is already abstract, and so a networking implementation can always return a File implementation, but certain low-level "syscall" specific operations would not be applicable.At least that has been my understanding. I am curious what the designers think.-Original Message- From: Matt Layher Sent: Mar 25, 2019 1:46 PM To: golang-nuts Subject: Re: [go-nuts] net.Conn types: File vs SyscallConn method The interface is defined in a file in syscall that exists on all platforms: https://golang.org/src/syscall/net.go?s=219:984#L1.Any operations you'd want to perform with it would probably invoke OS-specific APIs, but the same rule applies to using the file descriptor directly after invoking File.So my question still stands, as far as I know.On Monday, March 25, 2019 at 2:36:29 PM UTC-4, Robert Engels wrote:File is cross-platform. I am pretty sure no syscall. is guaranteed to be available on any given platform.-Original Message- From: Matt Layher Sent: Mar 25, 2019 1:03 PM To: golang-nuts Subject: [go-nuts] net.Conn types: File vs SyscallConn method 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...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- // Conn is implemented by some types in the net and os packages to provide// access to the underlying file descriptor or handle. 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. -- 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.
Re: [go-nuts] net.Conn types: File vs SyscallConn method
The interface is defined in a file in syscall that exists on all platforms: https://golang.org/src/syscall/net.go?s=219:984#L1. Any operations you'd want to perform with it would probably invoke OS-specific APIs, but the same rule applies to using the file descriptor directly after invoking File. So my question still stands, as far as I know. On Monday, March 25, 2019 at 2:36:29 PM UTC-4, Robert Engels wrote: > > File is cross-platform. I am pretty sure no syscall. is guaranteed to > be available on any given platform. > > -Original Message- > From: Matt Layher > Sent: Mar 25, 2019 1:03 PM > To: golang-nuts > Subject: [go-nuts] net.Conn types: File vs SyscallConn method > > 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...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > > > > -- 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.
Re: [go-nuts] net.Conn types: File vs SyscallConn method
File is cross-platform. I am pretty sure no syscall. is guaranteed to be available on any given platform.-Original Message- From: Matt Layher Sent: Mar 25, 2019 1:03 PM To: golang-nuts Subject: [go-nuts] net.Conn types: File vs SyscallConn method 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. -- 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.
[go-nuts] net.Conn types: File vs SyscallConn method
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.
