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

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 1 improved benchmark
❌ 1 regressed benchmark
✅ 124 untouched benchmarks

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	into_i128_pos_max	1.5 µs	2 µs	-24.69%
⚡	drop_many_objects_without_gil	48.1 µs	36.9 µs	+30.57%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing Person-93:no_std_mutex (8db26fd) with main (5c6807d)}

[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.