In Go, when is SyscallConn() useful for regular *os.File?

Question content

I am reading some instructions on using SyscallConn() (on *os.File defined function) Go code (from https://github.com/KarpelesLab/reflink):

// reflinkInternal performs the actual reflink action without worrying about fallback
func reflinkInternal(d, s *os.File) error {
    ss, err := s.SyscallConn()
    if err != nil {
        return err
    }
    sd, err := d.SyscallConn()
    if err != nil {
        return err
    }
    var err2, err3 error
    err = sd.Control(func(dfd uintptr) {
        err2 = ss.Control(func(sfd uintptr) {
            // int ioctl(int dest_fd, FICLONE, int src_fd);
            err3 = unix.IoctlFileClone(int(dfd), int(sfd))
        })
    })
    if err != nil {
        // sd.Control failed
        return err
    }
    if err2 != nil {
        // ss.Control failed
        return err2
    }
    if err3 != nil && errors.Is(err3, unix.ENOTSUP) {
        return ErrReflinkFailed
    }
    // err3 is ioctl() response
    return err3
}

In this example, use these Control() functions instead of directly using d.Fd() and s.Fd() Is there any Advantage? More generally, what is func func (*os.File) SyscallConn() (syscall.RawConn, error) used for?

Correct answer

##file.Fd() Returns a file descriptor, and it causes the file descriptor to run in blocking mode (occupying a thread for blocking operations). SyscallConn does not do this. In fact, it was created specifically to get a file descriptor without blocking it. See this question for more information.

The above is the detailed content of In Go, when is SyscallConn() useful for regular *os.File?. For more information, please follow other related articles on the PHP Chinese website!