Skip to content

Tracking Issue for sync_poison_mod #134646

@tgross35

Description

@tgross35
Contributor

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

Unresolved Questions

  • None yet.

Related

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

Activity

added
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
E-easyCall 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.
on Dec 22, 2024
GrigorenkoPV

GrigorenkoPV commented on Dec 23, 2024

@GrigorenkoPV
Contributor

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

added 3 commits that reference this issue on Jan 1, 2025
GrigorenkoPV

GrigorenkoPV commented on Jan 23, 2025

@GrigorenkoPV
Contributor

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.

changed the title [-]Tracking Issue for `sync_poison`[/-] [+]Tracking Issue for `sync_poison_mod`[/+] on Jan 23, 2025
added a commit that references this issue on Mar 11, 2025
bstrie

bstrie commented on May 6, 2025

@bstrie
Contributor

Can we get the libs-api team to nominate this for FCP? @Amanieu ?

tgross35

tgross35 commented on May 6, 2025

@tgross35
ContributorAuthor

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.

connortsui20

connortsui20 commented on Aug 4, 2025

@connortsui20
Contributor

Coming from #144872 I have this question:

Does it make sense to move LazyLock into the poison module? It is certainly a poison-able type, but at the same time it is slightly different from the 4 other types currently in the poison module in that it is unrecoverable. I think this is more of a libs-api 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 the poison module" (see #144185).

However, as I mention in #144872 the poisoning behavior of LazyLock is slightly different to those of Once, Rwlock, Mutex, and Condvar, in that they all allow recovery from poisoning (for Once the _force methods exist and for the others you can clear poison + use PoisonError::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 and nonpoison modules to have "identical" types. I think that there is already somewhat of an argument to be made against having a nonpoison::Once (see #134645 (comment)), and a nonpoison::LazyLock really does not make any sense even if poison::LazyLock exists.

tgross35

tgross35 commented on Aug 4, 2025

@tgross35
ContributorAuthor

I don't think there is any need to move things to poison/nonpoison if one of them isn't an obvious home. For LazyLock, 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 current Once as an implementation detail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

C-tracking-issueCategory: 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.E-help-wantedCall 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.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @bstrie@tgross35@GrigorenkoPV@connortsui20

      Issue actions

        Tracking Issue for `sync_poison_mod` · Issue #134646 · rust-lang/rust