- 03 6月, 2022 2 次提交
- 21 3月, 2022 1 次提交
-
-
由 Mara Bos 提交于
-
- 14 10月, 2020 2 次提交
-
-
由 Mara Bos 提交于
StaticMutex is only ever used with as a static (as the name already suggests). So it doesn't have to be generic over a lifetime, but can simply assume 'static. This 'static lifetime guarantees the object is never moved, so this is no longer a manually checked requirement for unsafe calls to lock().
-
由 Mara Bos 提交于
The comment said it's UB to call lock() while it is locked. That'd be quite a useless Mutex. :) It was supposed to say 'locked by the same thread', not just 'locked'.
-
- 09 10月, 2020 1 次提交
-
-
由 Mara Bos 提交于
-
- 02 10月, 2020 2 次提交
- 27 9月, 2020 1 次提交
-
-
由 Mara Bos 提交于
The (unsafe) Mutex from sys_common had a rather complicated interface. You were supposed to call init() manually, unless you could guarantee it was neither moved nor used reentrantly. Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if destroy() should only be called when `init()` was called. This allowed for a number of interesting (confusing?) different ways to use this Mutex, all captured in a single type. In practice, this type was only ever used in two ways: 1. As a static variable. In this case, neither init() nor destroy() are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the LockGuard, never with raw_lock. 2. As a Boxed variable. In this case, both init() and destroy() are called, it will be moved and possibly used reentrantly. No other combinations are used anywhere in `std`. This change simplifies things by splitting this Mutex type into two types matching the two use cases: StaticMutex and MovableMutex. The interface of both new types is now both safer and simpler. The first one does not call nor expose init/destroy, and the second one calls those automatically in its new() and Drop functions. Also, the locking functions of MovableMutex are no longer unsafe.
-
- 28 7月, 2020 1 次提交
-
-
由 mark 提交于
-
- 16 7月, 2020 1 次提交
-
-
由 Eric Huss 提交于
-
- 23 12月, 2019 1 次提交
-
-
由 Mark Rousskov 提交于
-
- 31 3月, 2019 1 次提交
-
-
由 Mazdak Farrokhzad 提交于
-
- 28 2月, 2019 1 次提交
-
-
由 Taiki Endo 提交于
-
- 18 2月, 2019 1 次提交
-
-
由 Scott McMurray 提交于
There are two big categories of changes in here - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop` & `Debug`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`) I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations where the flipped one cannot elide the lifetime.
-
- 26 12月, 2018 1 次提交
-
-
由 Mark Rousskov 提交于
-
- 11 12月, 2018 1 次提交
-
-
由 Oliver Scherer 提交于
-
- 07 12月, 2018 1 次提交
-
-
由 Jethro Beekman 提交于
-
- 10 11月, 2018 2 次提交
-
-
由 Mazdak Farrokhzad 提交于
-
由 Mazdak Farrokhzad 提交于
-
- 09 8月, 2018 1 次提交
-
-
由 Ralf Jung 提交于
-
- 06 8月, 2018 3 次提交
- 17 6月, 2018 1 次提交
-
-
由 NODA, Kai 提交于
Signed-off-by: NNODA, Kai <nodakai@gmail.com>
-
- 02 11月, 2016 1 次提交
-
-
由 Brian Anderson 提交于
Make the directory structure reflect the module structure. I've always found the existing structure confusing.
-
- 25 8月, 2016 1 次提交
-
-
由 Jeffrey Seyfried 提交于
-
- 02 6月, 2016 1 次提交
-
-
由 Amanieu d'Antras 提交于
The only applies to pthread mutexes. We solve this by creating the mutex with the PTHREAD_MUTEX_NORMAL type, which guarantees that re-locking from the same thread will deadlock.
-
- 27 5月, 2015 1 次提交
-
-
由 Eduard Burtescu 提交于
-
- 14 4月, 2015 1 次提交
-
-
由 Andrew Paseltiner 提交于
-
- 02 2月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This is an implementation of [RFC 578][rfc] which adds a new `std::env` module to replace most of the functionality in the current `std::os` module. More details can be found in the RFC itself, but as a summary the following methods have all been deprecated: [rfc]: https://github.com/rust-lang/rfcs/pull/578 * `os::args_as_bytes` => `env::args` * `os::args` => `env::args` * `os::consts` => `env::consts` * `os::dll_filename` => no replacement, use `env::consts` directly * `os::page_size` => `env::page_size` * `os::make_absolute` => use `env::current_dir` + `join` instead * `os::getcwd` => `env::current_dir` * `os::change_dir` => `env::set_current_dir` * `os::homedir` => `env::home_dir` * `os::tmpdir` => `env::temp_dir` * `os::join_paths` => `env::join_paths` * `os::split_paths` => `env::split_paths` * `os::self_exe_name` => `env::current_exe` * `os::self_exe_path` => use `env::current_exe` + `pop` * `os::set_exit_status` => `env::set_exit_status` * `os::get_exit_status` => `env::get_exit_status` * `os::env` => `env::vars` * `os::env_as_bytes` => `env::vars` * `os::getenv` => `env::var` or `env::var_string` * `os::getenv_as_bytes` => `env::var` * `os::setenv` => `env::set_var` * `os::unsetenv` => `env::remove_var` Many function signatures have also been tweaked for various purposes, but the main changes were: * `Vec`-returning APIs now all return iterators instead * All APIs are now centered around `OsString` instead of `Vec<u8>` or `String`. There is currently on convenience API, `env::var_string`, which can be used to get the value of an environment variable as a unicode `String`. All old APIs are `#[deprecated]` in-place and will remain for some time to allow for migrations. The semantics of the APIs have been tweaked slightly with regard to dealing with invalid unicode (panic instead of replacement). The new `std::env` module is all contained within the `env` feature, so crates must add the following to access the new APIs: #![feature(env)] [breaking-change]
-
- 07 1月, 2015 2 次提交
-
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
[breaking-change]
-
- 01 1月, 2015 1 次提交
-
-
由 Alex Crichton 提交于
This reverts commit 9e224c2b. Conflicts: src/libstd/sys/windows/os.rs
-
- 31 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
The new semantics of this function are that the callbacks are run when the *main thread* exits, not when all threads have exited. This implies that other threads may still be running when the `at_exit` callbacks are invoked and users need to be prepared for this situation. Users in the standard library have been audited in accordance to these new rules as well. Closes #20012
-
- 27 12月, 2014 2 次提交
-
-
由 Flavio Percoco 提交于
-
由 Flavio Percoco 提交于
-
- 20 12月, 2014 1 次提交
-
-
由 Eduard Burtescu 提交于
-
- 05 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
This commit is a reimplementation of `std::sync` to be based on the system-provided primitives wherever possible. The previous implementation was fundamentally built on top of channels, and as part of the runtime reform it has become clear that this is not the level of abstraction that the standard level should be providing. This rewrite aims to provide as thin of a shim as possible on top of the system primitives in order to make them safe. The overall interface of the `std::sync` module has in general not changed, but there are a few important distinctions, highlighted below: * The condition variable type, `Condvar`, has been separated out of a `Mutex`. A condition variable is now an entirely separate type. This separation benefits users who only use one mutex, and provides a clearer distinction of who's responsible for managing condition variables (the application). * All of `Condvar`, `Mutex`, and `RWLock` are now directly built on top of system primitives rather than using a custom implementation. The `Once`, `Barrier`, and `Semaphore` types are still built upon these abstractions of the system primitives. * The `Condvar`, `Mutex`, and `RWLock` types all have a new static type and constant initializer corresponding to them. These are provided primarily for C FFI interoperation, but are often useful to otherwise simply have a global lock. The types, however, will leak memory unless `destroy()` is called on them, which is clearly documented. * The `Condvar` implementation for an `RWLock` write lock has been removed. This may be added back in the future with a userspace implementation, but this commit is focused on exposing the system primitives first. * The fundamental architecture of this design is to provide two separate layers. The first layer is that exposed by `sys_common` which is a cross-platform bare-metal abstraction of the system synchronization primitives. No attempt is made at making this layer safe, and it is quite unsafe to use! It is currently not exported as part of the API of the standard library, but the stabilization of the `sys` module will ensure that these will be exposed in time. The purpose of this layer is to provide the core cross-platform abstractions if necessary to implementors. The second layer is the layer provided by `std::sync` which is intended to be the thinnest possible layer on top of `sys_common` which is entirely safe to use. There are a few concerns which need to be addressed when making these system primitives safe: * Once used, the OS primitives can never be **moved**. This means that they essentially need to have a stable address. The static primitives use `&'static self` to enforce this, and the non-static primitives all use a `Box` to provide this guarantee. * Poisoning is leveraged to ensure that invalid data is not accessible from other tasks after one has panicked. In addition to these overall blanket safety limitations, each primitive has a few restrictions of its own: * Mutexes and rwlocks can only be unlocked from the same thread that they were locked by. This is achieved through RAII lock guards which cannot be sent across threads. * Mutexes and rwlocks can only be unlocked if they were previously locked. This is achieved by not exposing an unlocking method. * A condition variable can only be waited on with a locked mutex. This is achieved by requiring a `MutexGuard` in the `wait()` method. * A condition variable cannot be used concurrently with more than one mutex. This is guaranteed by dynamically binding a condition variable to precisely one mutex for its entire lifecycle. This restriction may be able to be relaxed in the future (a mutex is unbound when no threads are waiting on the condvar), but for now it is sufficient to guarantee safety. * Condvars now support timeouts for their blocking operations. The implementation for these operations is provided by the system. Due to the modification of the `Condvar` API, removal of the `std::sync::mutex` API, and reimplementation, this is a breaking change. Most code should be fairly easy to port using the examples in the documentation of these primitives. [breaking-change] Closes #17094 Closes #18003
-