-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use io-lifetimes
types in API, instead of RawFd
#119
Conversation
Perhaps methods should take |
5352577
to
f2e1562
Compare
This is a bit hard to pull off successfully, with full I/O safety. For instance, let's say that a source is dropped before it's deregistered from the But then, you have a handful of options:
|
Strictly speaking I don't think that's undefined behavior, since calloop (at least with the backends implemented) doesn't actually keep the file descriptor. Epoll and kqueue maintain an association with the file description in-kernel. (If calloop implemented a backend for platforms that only support poll/select, this would be a concern. Presumably IOCP would be similar to epoll/kqueue in this context, but I'm not familiar with it.) Epoll(7) apparently will still deliver events after closing the fd if there are still fd's open to the same file description (if you dup an fd you get a new "file descriptor" referencing the same "file description"). Kqueue(2) says close will remove any kevents with that fd, but then it also says, "events which are attached to file descriptors are automatically deleted on the last close of the descriptor" (what is the "last close" if it's talking about descriptors?). So I think the poller shouldn't cause UB as long as the fd is valid at the time it is passed to one of the methods. Is there any case where this could lead to unexpected/undesired (but not "undefined") behavior, or inconsistencies between epoll and kqueue? |
Thanks LGTM overall. The CI error is not a fluke though, the calloop book needs to be adjusted for these changes, and this needs a changelog entry, as this is a breaking change (as illustrated by the book CI failure). Regarding safety, in particular:
First, unless your Second, my understanding is the save as @ids1024: closing an FD without deregistering from the poller would at most cause spurious wakeups of the event loop, no unsafety. |
Allows the `Display` to be used in `calloop::generic::Generic`, in combination with Smithay/calloop#119.
a7f1a1e
to
147e6b4
Compare
Operating on `RawFd`s is unsafe, so this should be changed. Though some uses will be cleaner once `nix` is updated for IO safety (which seems to be ongoing, but complicated). The `Rc<RefCell<IoDispatcher>>` in `Async` is somewhat awkward here. For now `Dispatcher` still contains a `RawFd`. The only alternative I can think of with how the API works is to use `Rc<F>` and have `into_inner` call `Rc::try_unwrap(self.fd).unwrap()`.
Adds an unsafe helper for wrapping an `AsRawFd` implementer in `AsFd`. Which is needed with things like zmq until they update to use IO safety traits: erickt/rust-zmq#361.
78d2fff
to
1cee2d9
Compare
Codecov ReportBase: 89.52% // Head: 89.28% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #119 +/- ##
==========================================
- Coverage 89.52% 89.28% -0.25%
==========================================
Files 17 17
Lines 1805 1838 +33
==========================================
+ Hits 1616 1641 +25
- Misses 189 197 +8
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Sorry for not saying this earlier, but maybe you could have it take |
As the API currently works, making What we might need to safely use things like |
Operating on
RawFd
s is unsafe, so this should be changed. Though some uses will be cleaner oncenix
is updated for IO safety (which seems to be ongoing, but complicated).The
Rc<RefCell<IoDispatcher>>
inAsync
is somewhat awkward here. For nowDispatcher
still contains aRawFd
. The only alternative I can think of with how the API works is to useRc<F>
and haveinto_inner
callRc::try_unwrap(self.fd).unwrap()
.