-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-help-wantedCall for participation: Help is requested to fix this issue.Call for participation: Help is requested to fix this issue.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Description
Feature gate: #![feature(sync_poison_mod)]
This is a tracking issue moving all poisonable std::sync
types to std::sync::poison
, with reexports in std::sync
. In a future edition, we will be able to instead reexport std::sync::nonpoison
(this module does not exist yet).
Public API
// std::sync::poison
type LockResult;
type TryLockResult;
struct Condvar { /* ... */ };
struct Mutex<T: ?Sized> { /* ... */ };
struct MutexGuard { /* ... */ };
struct Once { /* ... */ };
struct OnceState { /* ... */ };
struct PoisonError { /* ... */ };
struct RwLock { /* ... */ };
struct RwLockReadGuard { /* ... */ };
struct RwLockWriteGuard { /* ... */ };
enum TryLockError { /* ... */ };
// Unstable types
pub struct MappedMutexGuard<'a, T: ?Sized + 'a> { /* ... */ }
pub struct MappedRwLockReadGuard<'a, T: ?Sized + 'a> { /* ... */ }
pub struct MappedRwLockWriteGuard<'a, T: ?Sized + 'a> { /* ... */ }
// std::sync
// This module will be gated behind `sync_poison`
pub mod poison;
pub use poision::*;
Steps / History
- Final comment period (FCP)1Stabilization PRTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Unresolved Questions
- None yet.
Related
nonpoison
versions of existingpoison
types: Tracking Issue forsync_nonpoison
andnonpoison_{condvar,mutex,once,rwlock}
#134645ShouldLazyLock
be moved? Tracking Issue forsync_poison_mod
#134646 (comment)To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Footnotes
FliegendeWurst, connortsui20 and purplesyringa
Metadata
Metadata
Assignees
Labels
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-help-wantedCall for participation: Help is requested to fix this issue.Call for participation: Help is requested to fix this issue.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
sync_nonpoison
andnonpoison_{condvar,mutex,once,rwlock}
#134645GrigorenkoPV commentedon Dec 23, 2024
sync_poison
feature gate had already been used for some 1.2-stabilized APIs, which seems to have introduced poisoning in the first place.I propose using
sync_poison_mod
or something similar.Also,
@rustbot claim
std::sync::poison
and reexport them instd::sync
#134692Auto merge of rust-lang#134692 - GrigorenkoPV:sync_poision, r=tgross35
Auto merge of rust-lang#134692 - GrigorenkoPV:sync_poision, r=tgross35
Auto merge of rust-lang#134692 - GrigorenkoPV:sync_poision, r=tgross35
GrigorenkoPV commentedon Jan 23, 2025
The OP needs to be updated, since #134692 got merged. I believe the implementation is now finished, and the feature gate is actually
sync_poison_mod
.[-]Tracking Issue for `sync_poison`[/-][+]Tracking Issue for `sync_poison_mod`[/+]Auto merge of rust-lang#134692 - GrigorenkoPV:sync_poision, r=tgross35
bstrie commentedon May 6, 2025
Can we get the libs-api team to nominate this for FCP? @Amanieu ?
tgross35 commentedon May 6, 2025
I believe anybody can nominate via rustbot. But none of the nonpoison versions have been added yet, I don’t think it makes sense to stabilize this without knowing for sure that we have those.
LazyCell
andLazyLock
#144872connortsui20 commentedon Aug 4, 2025
Coming from #144872 I have this question:
My gut reaction would be that it does makes sense to move
LazyLock
into the poison module since it seems we are moving towards "things that involve poisoning in any sense of the meaning should go into thepoison
module" (see #144185).However, as I mention in #144872 the poisoning behavior of
LazyLock
is slightly different to those ofOnce
,Rwlock
,Mutex
, andCondvar
, in that they all allow recovery from poisoning (forOnce
the_force
methods exist and for the others you can clear poison + usePoisonError::into_inner
).It does not really make sense for
LazyLock
to have recoverable poisons since if the one and only initialization closure panics, it is unlikely that running it again is desirable (even if it is possible without a panic the second time).Then there is also a question of if we want the
poison
andnonpoison
modules to have "identical" types. I think that there is already somewhat of an argument to be made against having anonpoison::Once
(see #134645 (comment)), and anonpoison::LazyLock
really does not make any sense even ifpoison::LazyLock
exists.tgross35 commentedon Aug 4, 2025
I don't think there is any need to move things to
poison
/nonpoison
if one of them isn't an obvious home. ForLazyLock
, it's probably worth revisiting whether the current behavior w.r.t. poisoning is actually what we want, or if it's just a side effect of using the currentOnce
as an implementation detail.