Hacker News Reader

Comment by cyber_kinetist | Hacker News Reader

This relates to the fact that there's some talk going on in the Rust community to extend lifetime checks to domains outside of memory safety (like filesystems).

Here's an RFC that tries to extend lifetimes to file handles: https://github.com/rust-lang/rfcs/blob/master/text/3128-io-s...

View on HN

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?

File Descriptors are not files. They are unique per process so the rust compiler should be able to completely track their ownership.

No 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.

But 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.

The receiving process gets a copy of the file descriptor. Both processes must close(2) it.

If 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.

Reply on news.ycombinator.com