Tracking Issue for mutex_unpoison

[tmccombs]

Feature gate: #![feature(mutex_unpoison)]

This is a tracking issue for functions to clear the poisoned flag on Mutex and RwLock.

Public API

// std::sync

impl<T: ?Sized> Mutex<T> {
    pub fn clear_poison(&self);
}

impl<T: ?Sized> RwLock<T> {
    pub fn clear_poison(&self);
}

Steps / History

• https://internals.rust-lang.org/t/unpoisoning-a-mutex/16521
• Implementation: Add functions to un-poison Mutex and RwLock #96422
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[GilShoshan94]

Hi,

I read https://internals.rust-lang.org/t/unpoisoning-a-mutex/16521/3 (wich got automatically closed by the way) and the PR #96422.
It seems all good.

What is the next step to make it in the stable API ? Can I help somehow ?

[randommm]

Hi, sorry if flooding but are there any updates regarding this issue?

[tmccombs]

I think the next step is one of the rust developers needs to start the final comment period. IDK what the criteria for doing so are.

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

https://doc.rust-lang.org/nightly/std/sync/struct.Mutex.html#method.clear_poison
https://doc.rust-lang.org/nightly/std/sync/struct.RwLock.html#method.clear_poison

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[BurntSushi]

I was wondering whether the idea of putting this method on the guard had been considered and found that @m-ou-se's commentary (and the ensuring comments) addressed it. SGTM!

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[U007D]

Given the state change this method causes, I am curious about rationale behind using &self vs &mut self?

[bjorn3]

If it took &mut self, it wouldn't be possible to unpoison a mutex shared between threads despite that being the main case where poisoning can happen.

[AnthonyMikh]

I just want to add that probably before stabilizing this method we should implement a lint which catches invalid patterns of using these methods since it is very easy to misuse. Or, at the very least, include information about potential footgun in documentation for these methods.

[bjorn3]

What kind of lint do you exactly want? What are the patterns in question that you are worried about?

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[AnthonyMikh]

What kind of lint do you exactly want? What are the patterns in question that you are worried about?

@bjorn3 exactly the possible error outlined by Mara Bos: calling clear_poison before acquiring a lock. The only way this usage is correct is when no other thread can act on mutex - either because they don't exist or because they are all blocked on something else. I believe that these situations are rare enough to flag such a pattern as at least suspicious.

[randommm]

If unpoison was a method of PoisonError or of MutexGuard instead of mutex, would it prevent such problems?

[tmccombs]

That was discussed here:

#96422 (comment)