Call SyscallConn() instead of Fd() to use file's fd

[database64128]

os.File.SyscallConn is the safer alternative to os.File.Fd, without the pitfalls mentioned in Fd's doc comment.

The SyscallConn method is implemented on all platforms except Plan 9, where it returns syscall.EPLAN9, which matches errors.ErrUnsupported and goes to the fallback path.

[oschwald]

Could you expand on the pitfalls that are applicable to this use case? The file will not be closed or finalized before the memory map is open and we are not holding on to it.

[database64128]

Yes, in this use case it's safe to use Fd(). But SyscallConn is just strictly better than Fd in every aspect. It's like how the standard library is replacing the use of runtime.SetFinalizer with runtime.AddCleanup (golang/go#70907) after its introduction. The pitfalls of runtime.SetFinalizer may not apply to the existing uses, but it still makes sense to do the conversion.

Calling Fd() on an os.File has the side effect of putting the fd into blocking mode. This has potential future implications on our fallback path, when the Go runtime gains better support for async file IO. In Go 1.24 and earlier versions, os.File has no support for async file IO. Go 1.25 has undergone significant changes to support overlapped IO with os.File on Windows. Although they haven't made os.Open associate the fd with IOCP, they might do so in any future release, and then our use of Fd() would have caused the fd to be disassociated from IOCP (golang/go@8a8f506), which would cause our fallback path to tie up OS threads.