Re: [go-nuts] net.Conn types: File vs SyscallConn method

[Robert Engels]

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.XXXX 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.