-
Notifications
You must be signed in to change notification settings - Fork 161
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
feat: Expose the Solarish event ports API #503
Conversation
src/io/port.rs
Outdated
/// `port_associate()`- Associates a file descriptor with a port. | ||
pub fn port_associate_fd( | ||
port: &impl AsFd, | ||
object: &impl AsFd, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know what the behavior is if object is closed while it's associated with a port?
Also, is it possible to get the fd back from the port after this call?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know what the behavior is if object is closed while it's associated with a port?
Hmm, going through the man pages for OpenSolaris and illumos, I can't find any documentation for what happens. I'm assuming it's the same for epoll
and kqueue
, but you know that they say about assumptions.
Also, is it possible to get the fd back from the port after this call?
The object
method of the Event
structure contains the file descriptor. This can't be explicitly the FD because for EVENT_SOURCE_FILE
it may also be a pointer to a structure describing the file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's the file descriptor, then I'm nervous about AsFd
/BorrowedFd
in the same I am about them for kqueue
. It's important to me to be rigorous about borrows, even if there's no actual use-after-close hazard, because I'd like to eventually have things like I/O safety checking in miri. As in kqueue
, what would you think about using RawFd
and unsafe here?
The thing that hopefully makes this ok is that most users don't use these APIs directly; they're most often used in async runtimes and similar, which have to be carefully written, but then they can offer a higher-level abstraction to their users where it's easier to have safety invariants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
polling
uses RawFd
and unsafe
for now, and getting it to the point where it wouldn't would require some serious chicanery. I'll edit this PR and the kqueue
one to use RawFd
.
Spurious network failure :-/ I'll wait a few hours and then push an empty commit to hopefully kick the CI back into gear |
Fix unused unsafe warning Code review Use RawFd and unsafe in association fmt Get going! Empty commit to re-run the CI Fix 1.48 build
Looks good, thanks! |
This PR exposes the Solarish event ports API, which is Solaris' way of handling polling.