-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Add posix_fadvise()
and related constants
#177
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
Conversation
lgtm, will merge once CI is green |
Hm not entirely sure why travis didn't trigger here, perhaps a force push will fix that? |
Should I move some things around or something? |
Ah I think if you do |
Done. I see the build has been triggered this time. One possible concern is that Also, the |
Looks like this may not exist on OSX or on OpenBSD? Otherwise the signature seems to be agreed upon for supported arches |
Support appears to be inconsistent across BSD releases. It's in some but not in others, earlier or later. Should I just move it to |
Ah I'd be fine either way |
|
yes, OpenBSD supports |
Seems pretty arbitrary for OpenBSD but I'm fine moving this to |
Yeah that sounds good to me, just lemme know when it's pushed up! |
861e11d
to
c80fc21
Compare
Moved function declarations and constants to relevant files, rebased to upstream, and squashed. |
Add `posix_fadvise()` and related constants
Cheers! |
The returned length of AF_UNIX sockaddrs is significant, and generally does not match the length of the entire structure. For filesystem sockets, this is ignorable because the path is also NUL-terminated, but for unbound sockets (e.g., a socketpair) or abstract-namespace sockets (a Linux extension where the address is an arbitrary bytestring), we need to keep track of the length. Fixes rust-lang#177. Also add a UnixAddr::new_abstract function and some better handling of abstract-namespace socket addresses to fix rust-lang#169.
Closes #148
I didn't touch the
POSIX_MADV
constants, those can be consolidated in another PR.I also wrote a quick test to make sure that the call was written correctly and that
posix_fadvise()
actually works for my use-case:https://gist.github.com/cybergeek94/ce5e989c6ac6823acea4
As you can see, the uncached file takes much longer to read without the call to
posix_fadvise()
, which is exactly the result I wanted to see. A test file size of 8M is around what I'll be dealing with in my particular use-case (large libraries of images).cc @alexcrichton