Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for std::sync::Once poisoning #33577

Open
durka opened this issue May 12, 2016 · 12 comments
Open

Tracking issue for std::sync::Once poisoning #33577

durka opened this issue May 12, 2016 · 12 comments

Comments

@durka
Copy link
Contributor

@durka durka commented May 12, 2016

This tracks the once_poison feature, which currently covers the following things under std::sync::once:

  • OnceState, a struct describing the poisonedness of a Once
  • OnceState::poisoned, which reveals said poisonedness
  • Once::call_once_force, which is like call_once but ignores poisoning
durka added a commit to durka/rust that referenced this issue May 12, 2016
The tracking issue for once_poison was noted as rust-lang#31688 which was closed, so it now points to the new rust-lang#33577.
durka added a commit to durka/rust that referenced this issue May 21, 2016
The tracking issue for once_poison was noted as rust-lang#31688 which was closed, so it now points to the new rust-lang#33577.
Manishearth added a commit to Manishearth/rust that referenced this issue May 21, 2016
update tracking issue for once_poison

The tracking issue for once_poison was noted as rust-lang#31688 which was closed, so it now points to the new rust-lang#33577.
@brson
Copy link
Contributor

@brson brson commented Dec 29, 2016

This issue is primarily about the call_once_force method. Once implements poisoning, and this method is how you get around a poisoned Once.

@frewsxcv
Copy link
Member

@frewsxcv frewsxcv commented Oct 21, 2017

Anyone have insight why poisoned is not just a method on Once?

EDIT: nevermind

@dtolnay
Copy link
Member

@dtolnay dtolnay commented Nov 19, 2017

This naming seems inconsistent:

Could they both be is_poisoned since that one is stable already? Or is poisoned better enough that we should deprecate and rename the one on Mutex?

@joshlf
Copy link
Contributor

@joshlf joshlf commented Nov 19, 2017

Relevant: #43448 contains discussion of whether forking a process should cause poisoning of various synchronization primitives. TLDR: An option is to make it so that if you fork while a Once is in use, thus invalidating it, that Once becomes poisoned.

@steveklabnik
Copy link
Member

@steveklabnik steveklabnik commented Sep 16, 2019

Triage: no changes here that I'm aware of.

@sanmai-NL
Copy link

@sanmai-NL sanmai-NL commented Apr 30, 2020

#43448 was closed. @joshlf Can this issue be expedited, without discussing more than one scenario in which the state should be poisoned?

@joshlf
Copy link
Contributor

@joshlf joshlf commented Apr 30, 2020

Yes, the "poison on fork" proposal should be considered dead for the time being. The discussion in this issue can safely ignore that proposal.

@Amanieu
Copy link
Contributor

@Amanieu Amanieu commented Apr 30, 2020

I think this API is well designed and worth stabilizing. Note that parking_lot uses a difference OnceState, but I think the current one we have in libstd is fine as it is.

@rfcbot fcp merge

@rfcbot
Copy link

@rfcbot rfcbot commented Apr 30, 2020

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

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.

@rfcbot
Copy link

@rfcbot rfcbot commented May 1, 2020

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

@Kixunil
Copy link
Contributor

@Kixunil Kixunil commented May 2, 2020

Apart from consistency I find is_poisoned more clear than poisoned. The latter sounds a bit like a constructor that creates a poisoned instance.

@rfcbot
Copy link

@rfcbot rfcbot commented May 11, 2020

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.

The RFC will be merged soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.