Update Rust crate parking_lot to 0.13 #23
Loading…
Reference in a new issue
No description provided.
Delete branch "renovate/parking_lot-0.x"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR contains the following updates:
0.12→0.13Release Notes
Amanieu/parking_lot (parking_lot)
v0.13.0Compare Source
MutexandRwLockperformance under contention bydeferring waking up parked threads until after the lock is released. (#545)
lock_apiraw locks.RawMutex::Guardreplaces
GuardMarker; rwlocks have separateSharedGuard,ExclusiveGuard,and
UpgradableGuardtypes. Unlock operations consume this state, whileupgrade and downgrade operations return replacement state. Bump and raw
condition-variable waits borrow and update the state. Consuming operations
must release their acquisition on unwind; borrowing operations must restore
ownership and valid state, or abort if restoration fails. (#544)
hardware-lock-elisionfeature. (#533)the explicit fair-unlock APIs. This removes
UnparkResult::be_fair. (#533)lock_api/nightlyfeature. (#533)lock_apiconst_newmethods and the redundantparking_lotconst_*constructor functions; the correspondingnewmethods can be called in constant contexts. (#533)
RwLockwith a dedicated reader-biasedRecursiveRwLocktype. TheRawRwLockRecursiveandRawRwLockRecursiveTimedextension traits have been removed from
lock_api. (#533)Once::new_completedfor constructing aOncein the completed state. (#520)Once::{is_completed, wait, wait_force}and the correspondingOnceStatequery methods. (#533)constant contexts. (#533)
into_inner_with_rawtolock_api'sMutex,RwLock, andReentrantMutex. (#524)RawCondvar,RawCondvarTimed, and the genericCondvarwrapper tolock_api, and implementedparking_lot::Condvarusing them. Custom rawcondition variables may allow spurious wakeups; their notification methods
must then return
falseor0.parking_lot::Condvarstill guarantees nospurious wakeups and exact notification counts. (#523) (#533)
SendandSyncbounds of lock guards inlock_api. (#533)RawMutex::is_lockedandRawRwLock::{is_locked, is_locked_exclusive}required methods. (#533)MappedRwLockReadGuard::try_map_or_elsetotry_map_or_err. (#533)acquire/release synchronization, moving or dropping a locked raw lock,
preserving the original lock mode on a failed upgrade, and stable thread IDs.
Acquisitions may unwind without leaving a new acquisition held; consuming
guard operations release their acquisition on unwind, while bump and wait
operations must restore ownership or abort. (#533) (#544)
guard-construction APIs in
lock_api. (#533)unlockedandunlocked_fairoperations now abort if re-locking panics.Default raw-lock bump implementations also abort if re-locking panics. (#533)
with_upgradedoperations abort if raw upgrading or downgrading panics,preserving continuous lock ownership. (#544)
parking_lot_coreare now guaranteed to neverunwind. (#533)
internally by global allocators. (#533)
unlock_upgradable_fairnot forcing a fair handoff. (#533)Condvarwaits reporting a timeout without rechecking the predicate. (#533)intrinsics are unavailable, including on stable threaded WASI targets. (#538)
architectures, with fallback to time32 when the kernel lacks time64 support. (#533)
RwLockdeadlock tracking to avoid false positives and missedcycles, and prevented dependency feature unification from enabling tracking
when only
parking_lot_core/deadlock_detectionis enabled. (#533)Oncedeadlock tracking and made overlapping wait cycles report as asingle component. (#533)
Configuration
📅 Schedule: (in timezone America/Los_Angeles)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate CLI.