在 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) 有什麼用？

正確答案

file.Fd() 傳回一個檔案描述符，並且它使檔案描述符以阻塞模式運行（佔用一個線程以進行阻塞操作）。 SyscallConn 不這樣做。事實上，它是專門為了獲取文件描述符而不使其阻塞而創建的。請參閱此問題以了解更多資訊。

以上是在 Go 中，什麼時候 SyscallConn() 對常規 *os.File 有用？的詳細內容。更多資訊請關注PHP中文網其他相關文章！