Tracking Issue for `sync_poison`

[tgross35]

Feature gate: #![feature(sync_poison)]

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

• ACP: Adding locks disregarding poison libs-team#169 (comment)
• Implementation: #...
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Related

• nonpoison versions of existing poison types: Tracking Issue for sync_nonpoison and nonpoison_{condvar,mutex,once,rwlock} #134645

Footnotes

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

[GrigorenkoPV]

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