Add posix_fadvise() and related constants
#177
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! |
abonander
force-pushed
the
master
branch
2 times, most recently
from
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_MADVconstants, 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