在 Go 中，什么时候 SyscallConn() 对常规 *os.File 有用？

问题内容

我正在阅读一些使用 SyscallConn() （在 *os.File 上定义的函数）的 Go 代码（来自 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
}

在此示例中，使用这些 Control() 函数而不是直接使用 d.Fd() 和 s.Fd() 是否有任何优势？更一般地说， func func (*os.File) SyscallConn() (syscall.RawConn, error) 有什么用？ Control() 函数而不是直接使用 d.Fd() 和 s.Fd() 是否有任何优势？更一般地说， func func (*os.File) SyscallConn() (syscall.RawConn, error) 有什么用？

正确答案

file.Fd() 返回一个文件描述符，并且它使文件描述符以阻塞模式运行（占用一个线程以进行阻塞操作）。 SyscallConn

正确答案

file.Fd() 返回一个文件描述符，并且它使文件描述符以阻塞模式运行（占用一个线程以进行阻塞操作）。 SyscallConn 不这样做。事实上，它是专门为了获取文件描述符而不使其阻塞而创建的。请参阅🎜此问题了解更多信息🎜。🎜

以上是在 Go 中，什么时候 SyscallConn() 对常规 *os.File 有用？的详细内容。更多信息请关注PHP中文网其他相关文章！