The examples for both hash_map::OccupiedEntry::get_mut and
hash_map::OccupiedEntry::into_mut were almost identical. This led
to some confusion over the difference, namely why you would ever
use get_mut when into_mut gives alonger lifetime. Reddit thread:
https://www.reddit.com/r/rust/comments/8a5swr/why_does_hashmaps
This commit adds two lines and a comment to the example, to show
that the entry object can be re-used after calling get_mut.
Make the OOM hook return `()` rather than `!`
Per discussion in https://github.com/rust-lang/rust/issues/51245#issuecomment-393651083
This allows more flexibility in what can be done with the API. This also
splits `rtabort!` into `dumb_print` happening in the default hook and
`abort_internal`, happening in the actual oom handler after calling the
hook. Registering an empty function thus makes the oom handler not print
anything but still abort.
Cc: @alexcrichton
Per discussion in https://github.com/rust-lang/rust/issues/51245#issuecomment-393651083
This allows more flexibility in what can be done with the API. This also
splits `rtabort!` into `dumb_print` happening in the default hook and
`abort_internal`, happening in the actual oom handler after calling the
hook. Registering an empty function thus makes the oom handler not print
anything but still abort.
Cc: @alexcrichton
fs: copy: Use File::set_permissions instead of fs::set_permissions
We already got the open file descriptor at this point.
Don't make the kernel resolve the path again.
Update libbacktrace
We haven't updated libbacktrace in two years. This is just blindly updating to the latest HEAD; I'd like to see what travis says. It at least builds on my machine, running some tests...
This perpetuates the patches from https://github.com/rust-lang/rust/pull/30908
While we're at it update the `backtrace` crate from crates.io. It turns out that
the submodule's configure script has gotten a lot more finnicky as of late so
also switch over to using the `cc` crate manually which allows to avoid some
hacks around the configure script as well
OOM handling changes
As discussed in https://github.com/rust-lang/rust/issues/49668#issuecomment-384893456 and subsequent.
This does have codegen implications. Even without the hooks, and with a handler that ignores the arguments, the compiler doesn't eliminate calling `rust_oom` with the `Layout`. Even if it managed to eliminate that, with the hooks, I don't know if the compiler would be able to figure out it can skip it if the hook is never set.
A couple implementation notes:
- I went with explicit enums rather than bools because it makes it clearer in callers what is being requested.
- I didn't know what `feature` to put the hook setting functions behind. (and surprisingly, the compile went through without any annotation on the functions)
- There's probably some bikeshedding to do on the naming.
Cc: @Simonsapin, @sfackler
fs: copy: use copy_file_range on Linux
Linux 4.5 introduced a new system call [copy_file_range](http://man7.org/linux/man-pages/man2/copy_file_range.2.html) to copy data from one file to another.
This PR uses the new system call (if available). This has several advantages:
1. No need to constantly copy data from userspace to kernel space, if the buffer is small or the file is large
2. On some filesystems, like BTRFS, the kernel can leverage internal fs mechanisms for huge performance gains
3. Filesystems on the network dont need to copy data between the host and the client machine (they have to in the current read/write implementation)
I have created a small library that also implements the new system call for some huge performance gains here: https://github.com/nicokoch/fastcopy
Benchmark results are in the README
As discussed in
https://github.com/rust-lang/rust/issues/49668#issuecomment-384893456
and subsequent, there are use-cases where the OOM handler needs to know
the size of the allocation that failed. The alignment might also be a
cause for allocation failure, so providing it as well can be useful.
Implement From for more types on Cow
This is basically https://github.com/rust-lang/rust/pull/48191, except that it should be implemented in a way that doesn't break third party crates.
read2: Use inner function instead of closure
Very minor thing, but there doesn't appear to be a reason to use a closure here.
Generated code is identical in my tests, but I believe it's clearer that nothing from the environment is being used.
Don't unconditionally set CLOEXEC twice on every fd we open on Linux
Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`,
because some old Linux version would ignore the `O_CLOEXEC` flag we pass
to the `open64` function.
Now, we check whether the `CLOEXEC` flag is set on the first file we
open – if it is, we won't do extra syscalls for every opened file. If it
is not set, we fall back to the old behavior of unconditionally calling
`ioctl(…, FIOCLEX)` on newly opened files.
On old Linuxes, this amounts to one extra syscall per process, namely
the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag.
On new Linuxes, this reduces the number of syscalls per opened file by
one, except for the first file, where it does the same number of
syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of
`ioctl(…, FIOCLEX)` to set it).
