Add a raw file descriptor context

[notgull]

This PR adds an unsafe Context for using a raw file descriptor. It is unsafe to instantiate, assuring that users do not use it for shenanigans.

[SUPERCILEX]

Why not use unsafe { BorrowedFd::borrow_raw(fd) }? Then the lib doesn't need to use RawFd types.

[notgull]

This would require the file descriptor being borrowed for the lifetime of the Epoll. For the async-io use case, this would be 'static. While this is possible, it's less sanitary than just having an escape hatch for using raw file descriptors.

[SUPERCILEX]

Hmmm, then maybe https://docs.rs/rustix/latest/rustix/io/epoll/struct.Epoll.html#impl-FromRawFd-for-Epoll%3COwning%3C%27context%2C%20T%3E%3E optionally wrapped with a ManuallyDrop if you can't actually own the fd? Or just ignore me, this is just a gut reaction flyby against RawFd anyway. :)

[notgull]

optionally wrapped with a ManuallyDrop if you can't actually own the fd?

At that point, a ManuallyDrop<OwnedFd> loses most of the advantages that it has over a RawFd in terms of I/O safety. Although I definitely support a strong aversion to unsafe code, sometimes an escape hatch is better than a lifetime/drop hack.

[SUPERCILEX]

At that point, a ManuallyDrop loses most of the advantages that it has over a RawFd in terms of I/O safety.

I'd say that's partially fair. OwnedFds (assuming correct construction) at least provide aliasing guarantees so you don't run into the ABA problem on drop (can't have two OwnedFds with the same FD).

sometimes an escape hatch is better than a lifetime/drop hack.

100% agree there.

I'm actually curious now: is the idea to use rustix epoll here?
https://github.com/smol-rs/polling/blob/5343302970dc0167bee4c3cdf56e99862b3a4d87/src/epoll.rs#L16-L23

Why wouldn't you want OwnedFds?

[notgull]

I'm actually curious now: is the idea to use rustix epoll here?

Yes, the idea is to port parts of our code to rustix, not only for the safety guarantees but for the direct syscalls. See this discussion.

Why wouldn't you want OwnedFds?

We assume that we still have access to the I/O source, so losing access to the OwnedFd for the duration of the wait would require a breaking API change in async-io, and probably end up being horribly unergonomic anyways.

[SUPERCILEX]

Ok, I think I get the issue. On this line, you would need to either pass in an OwnedFd or BorrowedFd. Using OwnedFd is infeasible b/c you would need to move the io handle out of the Async while waiting for completion. Similarly, BorrowedFd doesn't work b/c you need to be able to modify/delete epoll IOs outside of the Async's calling context (so the lifetimes won't work). If I got that right, then yeah, RawFd seems to be the way to go.

[notgull]

Obsolete after #487