internal: no std mutex

[Person-93]

This PR is to prepare for no_std support.

I've added non_poison::Mutex and Once to the platform mod.

There was once place that relied on poisoning for correctness: err_state.rs, but that didn't really need a mutex because it was guarding a Copy type, I've replaced it with a Cell.

[codspeed-hq]

Merging this PR will not alter performance

✅ 126 untouched benchmarks

---

_{Comparing Person-93:no_std_mutex (54f935c) with main (4c8407d)}

[davidhewitt]

I think we should have (in order of preference)

• std mutex
• if std not enabled, fallback to parking_lot mutex
• if parking_lot not enabled, compile error

In the absence of a std feature at the moment, perhaps we can have a #[cfg(wip_no_std)] which is the equivalent of what will become #[cfg(not(feature = "std"))]. We could tweak the noxfile to send this via a cfg for one of the test combinations.

[Person-93]

In the absence of a std feature at the moment, perhaps we can have a #[cfg(wip_no_std)] which is the equivalent of what will become #[cfg(not(feature = "std"))]. We could tweak the noxfile to send this via a cfg for one of the test combinations.

That's a good idea, but I think that the custom cfg should be the other way around; something like wip_feature_std so that we can do #[cfg(wip_feature_std)] or #[cfg(not(wip_feature_std))] and then just search-and-replace when we are ready to add the std feature.

[Person-93]

I think we should have (in order of preference)

• std mutex
• if std not enabled, fallback to parking_lot mutex
• if parking_lot not enabled, compile error

I thought I'd try for the low-hanging performance gain of parking lot's mutex, but I can do it this way instead.

[davidhewitt]

I believe it is context-dependent what mutex performs better, see e.g. https://blog.cuongle.dev/p/inside-rusts-std-and-parking-lot-mutexes-who-win

My take is that generally PyO3 internal mutexes mostly sit in the low-contention space where zero dependencies is a perk.

[davidhewitt]

In the absence of a std feature at the moment, perhaps we can have a #[cfg(wip_no_std)] which is the equivalent of what will become #[cfg(not(feature = "std"))]. We could tweak the noxfile to send this via a cfg for one of the test combinations.

That's a good idea, but I think that the custom cfg should be the other way around; something like wip_feature_std so that we can do #[cfg(wip_feature_std)] or #[cfg(not(wip_feature_std))] and then just search-and-replace when we are ready to add the std feature.

If that works, also happy with it. The constraint I think we have is that we can't apply a non-feature cfg by default, so we'll need to make sure that whatever we add evaluates to true unless the cfg is explicitly passed by flags.

[Person-93]

Here's what I've come up with:

The build script enables the cfg wip_std_feature by default, and you can set the env var PYO3_WIP_NO_STD=1 to disable it.