std::thread docs: spawn() does not return a Thread anymore
Also move the "Thread type" section down a bit, since it is not so important anymore.
Fixes: #33321
rand: don't block before random pool is initialized
If we attempt a read with getrandom() on Linux the syscall can block
before the random pool is initialized unless the GRND_NONBLOCK flag is
passed. This flag causes getrandom() to instead return EAGAIN while the
pool is uninitialized. To avoid downstream users of crate or std
functionality that have no ability to avoid this blocking behavior this
change causes Rust to read bytes from /dev/urandom while getrandom()
would block and once getrandom() is available to use that. Fixes#32953.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Panic on overflow in `Duration::new` constructor
Panicking on overflow is also done for `+`, and it replaces the
currently incorrect overflow behavior of wrapping around, which does not
make sense for `Duration`s.
std: Add compatibility with android-9
The Gecko folks currently use Android API level 9 for their builds, so they're
requesting that we move back our minimum supported API level from 18 to 9. Turns
out, ABI-wise at least, there's not that many changes we need to take care of.
The `ftruncate64` API appeared in android-12 and the `log2` and `log2f` APIs
appeared in android-18. We can have a simple shim for `ftruncate64` which falls
back on `ftruncate` and the `log2` function can be approximated with just
`ln(f) / ln(2)`.
This should at least get the standard library building on API level 9, although
the tests aren't quite happening there just yet. As we seem to be growing a
number of Android compatibility shims, they're now centralized in a common
`sys::android` module.
Make HashSet::Insert documentation more consistent
I have made the HashSet::Insert documentation more consistent in the use of the term 'value' vs 'key'. Also clarified that if _this_ value is present true is returned, instead of the ambiguous 'a value present'.
r? @steveklabnik
The Gecko folks currently use Android API level 9 for their builds, so they're
requesting that we move back our minimum supported API level from 18 to 9. Turns
out, ABI-wise at least, there's not that many changes we need to take care of.
The `ftruncate64` API appeared in android-12 and the `log2` and `log2f` APIs
appeared in android-18. We can have a simple shim for `ftruncate64` which falls
back on `ftruncate` and the `log2` function can be approximated with just
`ln(f) / ln(2)`.
This should at least get the standard library building on API level 9, although
the tests aren't quite happening there just yet. As we seem to be growing a
number of Android compatibility shims, they're now centralized in a common
`sys::android` module.
clarify documentation of TcpStream::connect() for multiple valid addresses
I am not sure how the UDP part of the stdlib behaves when passing multiple valid addresses, but it should be mentioned as there are legit use cases for [`impl<'a> ToSocketAddrs for &'a [SocketAddr]`](http://doc.rust-lang.org/nightly/std/net/trait.ToSocketAddrs.html), a TCP fallback only being one.
Just a little example program for anyone willing to enhance the documentation further:
```rust
use std::net::SocketAddr;
use std::net::ToSocketAddrs;
use std::net::TcpStream;
fn main()
{
let v: Vec<SocketAddr> = vec!
[
"127.0.0.1:1338".to_socket_addrs().unwrap().next().unwrap(),
"127.0.0.1:1337".to_socket_addrs().unwrap().next().unwrap(),
"127.0.0.1:1339".to_socket_addrs().unwrap().next().unwrap(),
];
let stream = TcpStream::connect(&v[..]).unwrap();
}
```
Remove IPV6_V6ONLY functionality
These settings can only be adjusted before bind time, which doesn't make
sense in the current set of functionality. These methods are stable, but
haven't hit a stable release yet.
Closes#33052
[breaking-change]
r? @alexcrichton
Will also need a backport to the beta.
The algorithm implemented here is linear in the size of the two b-trees. It
firsts creates a `MergeIter` from the two b-trees and then builds a new b-tree
by pushing key-value pairs from the `MergeIter` into nodes at the right heights.
Three functions for stealing have been added to the implementation of `Handle` as
well as a getter for the height of a `NodeRef`.
The docs have been updated with performance information about `BTreeMap::append` and
the remark about B has been removed now that it is the same for all instances of `BTreeMap`.
These settings can only be adjusted before bind time, which doesn't make
sense in the current set of functionality. These methods are stable, but
haven't hit a stable release yet.
Closes#33052
[breaking-change]
Add some comments so that people know why we are performing a fallback
from getrandom() and what that fallback aims to achieve.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
The random functions that HashMap use make no guarantees about the
quality of random data so this documents that to the user so that they
are aware. This was brought about by the change to the Linux random code
to not block until the urandom pool was initialized to avoid users of
crates that internally use HashMap being caught unaware and having their
application block until the urandom pool is initialized.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
If we attempt a read with getrandom() on Linux the syscall can block
before the random pool is initialized unless the GRND_NONBLOCK flag is
passed. This flag causes getrandom() to instead return EAGAIN while the
pool is uninitialized. To avoid downstream users of crate or std
functionality that have no ability to avoid this blocking behavior this
change causes Rust to read bytes from /dev/urandom while getrandom()
would block and once getrandom() is available to use that. Fixes#32953.
Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
Panicking on overflow is also done for `+`, and it replaces the
currently incorrect overflow behavior of wrapping around, which does not
make sense for `Duration`s.
