4 ms·
Interesting RFC. I'm interested in how something like `OwnedFd` can work. In what sense is it "owned"? What's stopping the OS from deleting/changing the file un
by milliams 5y ago
Interesting RFC. I'm interested in how something like `OwnedFd` can work. In what sense is it "owned"? What's stopping the OS from deleting/changing the file underneath it? Do OS's provide some API to this end, or will the Rust std library do some checks before allowing operations on it?
- voxic11 5y agoFile Descriptors are not files. They are unique per process so the rust compiler should be able to completely track their ownership.
- hn_go_brrrrr 5y agoNo they're not. Other processes can pass you an fd at startup, you can send/receive fds across a Unix domain socket, and there are even syscalls for copying another process's fds.
- estebank 5y agoBut another process wouldn't be passing an OwnedFd in that case, and sending an OwnedFd away would pass the underlying FD and drop the wrapping OwnedFd. The process receiving the FD would have to take care (as today in any C program) to determine whether they are responsible dispose of the FD or not.
- brandmeyer 5y agoThe receiving process gets a copy of the file descriptor. Both processes must close(2) it.
- brandmeyer 5y agoIf process A opens a file and passes a file descriptor to process B, then process B's descriptor will continue to refer to the same object regardless of what process A does. Process A can unlink the descriptor, swap the directory entry out for some other object or whatever, and Process B will still have a handle to the same initial object. Nothing stops A from mutating the filesystem object in other ways. For example, A's write to the middle of the file or truncation of the file will be visible to B. But merely unlinking the file doesn't alter B's view of the object.