Non-poisoning Mutexes

113 points connor-ts 73 comments

I wanted to post this here for more visibility since it has generated more discussion on GitHub recently (which I see as a great thing since it has felt a bit dormant recently!).

The discussion comes from this tracking issue for non-poisoning locks. The idea is that the current poisoning API is likely overkill or unnecessary for a large majority of cases where you want to use locks.

Here's a high-level summary of the history of this change if you don't want to read through the the tracking issues:

  • The idea came from an API change proposal almost 2 years ago.
  • The existing locks were moved to the poison module (and re-exported back up to sync).
  • The 3 lock types that work with poisoning(1) (Mutex, Condvar, RwLock) had non-poisoning equivalents implemented.

My understanding is that in the Libs-API team meetings, they concluded that we could change the default poisoning locks to non-poisoning locks over an edition boundary (likely 2027).

Now that we have the non-poisoning locks implemented(2) and the API for these has mostly been figured out, what are people's thoughts on this? Testing these types on nightly is super helpful for this.

Personally, I care more that both types exist more than "which one is the default", which is what the linked issue is describing.


1: Technically there were 4 with Once but we decided it didn't really fit the same model of poisoning as the other 3.

2: I'll toot my own horn here for a second, this was my first large contribution to the standard library! Obviously I didn't do it by myself and had a lot of help, but this probably explains my stake in this.

Edit: Apparently footnotes don't work on Reddit