| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
|
|
remove trailing whitespace
|
|
should consume this notification, so prohibit spurious wakeups in next park
|
|
fs: copy: Add EPERM to fallback error conditions
Fixes #51266
|
|
Remove feature flag from fs::read_to_string example
This is stable, and so no longer needed
|
|
|
|
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
|
|
This is stable, and so no longer needed
|
|
Fixes #51266
|
|
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.
|
|
When subtracting an Instant from another, the function will panick when `RHS > self`, but the error message confusingly displays a different error:
```rust
let i = Instant::now();
let other = Instant::now();
if other > i {
println!("{:?}", i - other);
}
```
This results in a panic:
```
thread 'test_instant' panicked at 'other was less than the current instant', libstd/sys/unix/time.rs:292:17
```
|
|
|
|
|
|
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
|
|
|
|
We already got the open file descriptor at this point.
Don't make the kernel resolve the path again.
|
|
|
|
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
|
|
- compute bytes_to_copy more elegantly
- add assert that written is 0 in fallback case
|
|
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.
|
|
|
|
branch
|
|
Mention and use `Once::new` instead of `ONCE_INIT`
|
|
Add documentation about env! second argument
Fixes #48044.
r? @QuietMisdreavus
|
|
|
|
- Move loading of atomic bool outside the loop
- Add comment about TryFrom for future improvement
|
|
|
|
|
|
was already moved to ops::RangeBounds (see #30877)
|
|
|
|
|
|
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.
|
|
Stabilize num::NonZeroU*
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
env: remove unwrap in examples in favor of try op
|
|
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.
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
