vendor/parking_lot-0.9.0/CHANGELOG.md

   1 ## parking_lot 0.9.0, parking_lot_core 0.6.0, lock_api 0.3.1 (2019-07-14)
   2
   3 - The minimum supported rust version (MSRV) is now 1.32. This was primarily
   4   increased for testing with the latest _rand_ crate. Rust 1.31 may continue to
   5   work for normal use of these releases.
   6 - Re-export lock_api (0.3.1) from parking_lot (#150)
   7 - Removed (non-dev) dependency on rand crate for fairness mechanism, by
   8   including a simple xorshift PRNG in core (#144)
   9 - Android now uses the futex-based ThreadParker. (#140)
  10 - Fixed CloudABI ThreadParker. (#140)
  11 - Fix race condition in lock_api::ReentrantMutex (da16c2c7)
  12
  13 ## lock_api 0.3.0 (2019-07-03, _yanked_)
  14
  15 - Use NonZeroUsize in GetThreadId::nonzero_thread_id (#148)
  16 - Debug assert lock_count in ReentrantMutex (#148)
  17 - Tag as `unsafe` and document some internal methods (#148)
  18 - This release was _yanked_ due to a regression in ReentrantMutex (da16c2c7)
  19
  20 ## parking_lot 0.8.1 (2019-07-03, _yanked_)
  21
  22 - Re-export lock_api (0.3.0) from parking_lot (#150)
  23 - This release was _yanked_ from crates.io due to unexpected breakage (#156)
  24
  25 ## parking_lot 0.8.0, parking_lot_core 0.5.0, lock_api 0.2.0 (2019-05-04)
  26
  27 - Fix race conditions in deadlock detection.
  28 - Support for more platforms by adding ThreadParker implementations for
  29   Wasm, Redox, SGX and CloudABI.
  30 - Drop support for older Rust. parking_lot now requires 1.31 and is a
  31   Rust 2018 edition crate (#122).
  32 - Disable the owning_ref feature by default.
  33 - Fix was_last_thread value in the timeout callback of park() (#129).
  34 - Support single byte Mutex/Once on stable Rust when compiler is at least
  35   version 1.34.
  36 - Make Condvar::new and Once::new const fns on stable Rust and remove
  37   ONCE_INIT (#134).
  38 - Add optional Serde support (#135).
  39
  40 ## parking_lot 0.7.1 (2019-01-01)
  41
  42 - Fixed potential deadlock when upgrading a RwLock.
  43 - Fixed overflow panic on very long timeouts (#111).
  44
  45 ## parking_lot 0.7.0, parking_lot_core 0.4.0 (2018-11-26)
  46
  47 - Return if or how many threads were notified from `Condvar::notify_*`
  48
  49 ## parking_lot 0.6.3 (2018-07-18)
  50
  51 - Export `RawMutex`, `RawRwLock` and `RawThreadId`.
  52
  53 ## parking_lot 0.6.2 (2018-06-18)
  54
  55 - Enable `lock_api/nightly` feature from `parking_lot/nightly` (#79)
  56
  57 ## parking_lot 0.6.1 (2018-06-08)
  58
  59 Added missing typedefs for mapped lock guards:
  60
  61 - `MappedMutexGuard`
  62 - `MappedReentrantMutexGuard`
  63 - `MappedRwLockReadGuard`
  64 - `MappedRwLockWriteGuard`
  65
  66 ## parking_lot 0.6.0 (2018-06-08)
  67
  68 This release moves most of the code for type-safe `Mutex` and `RwLock` types
  69 into a separate crate called `lock_api`. This new crate is compatible with
  70 `no_std` and provides `Mutex` and `RwLock` type-safe wrapper types from a raw
  71 mutex type which implements the `RawMutex` or `RawRwLock` trait. The API
  72 provided by the wrapper types can be extended by implementing more traits on
  73 the raw mutex type which provide more functionality (e.g. `RawMutexTimed`). See
  74 the crate documentation for more details.
  75
  76 There are also several major changes:
  77
  78 - The minimum required Rust version is bumped to 1.26.
  79 - All methods on `MutexGuard` (and other guard types) are no longer inherent
  80   methods and must be called as `MutexGuard::method(self)`. This avoids
  81   conflicts with methods from the inner type.
  82 - `MutexGuard` (and other guard types) add the `unlocked` method which
  83   temporarily unlocks a mutex, runs the given closure, and then re-locks the
  84    mutex.
  85 - `MutexGuard` (and other guard types) add the `bump` method which gives a
  86   chance for other threads to acquire the mutex by temporarily unlocking it and
  87   re-locking it. However this is optimized for the common case where there are
  88   no threads waiting on the lock, in which case no unlocking is performed.
  89 - `MutexGuard` (and other guard types) add the `map` method which returns a
  90   `MappedMutexGuard` which holds only a subset of the original locked type. The
  91   `MappedMutexGuard` type is identical to `MutexGuard` except that it does not
  92   support the `unlocked` and `bump` methods, and can't be used with `CondVar`.