No std pymutex - nonpoisoning variant of PyMutex

[Person-93]

Closes #6436

[davidhewitt]

This seems reasonable to me; did you have a particular use case or just fed up of .lock().unwrap()?

[davidhewitt]

Do you think we could re-use the existing mutex tests using PyMutexTrait? Should we? (Except for poisoning tests.)

[Person-93]

I'm not sure because they aren't exactly the same. We could use some trait to hide the differences but that feels a bit more error prone than I'd like for a test case. Like the mini-framework itself would need testing.

On the other hand, any future changes to these tests would need to be duplicated in both file.

[davidhewitt]

I wonder, if f panics should the mutex(es) be poisoned (if using the poisoning variant)? Probably yes. cc @ngoldbaum we might have overlooked this in the original introduction of this function.

I guess we could change the behaviour to poison on unwind, it would probably not break anyone and we could document it in the migration guide?

[Person-93]

It looks like it already does poison on unwind.

pyo3/src/sync/mutex.rs

Lines 247 to 253 in 58cb851

	impl<'a, T: ?Sized> Drop for PyMutexGuard<'a, T> {
	fn drop(&mut self) {
	self.inner.poison.done(&self.poison);
	// SAFETY: valid pointer to mutex passed to `PyMutex_Unlock`
	unsafe { crate::ffi::PyMutex_Unlock(self.inner.mutex.get()) };
	}
	}

pyo3/src/sync/mutex.rs

Lines 52 to 57 in 58cb851

	#[cfg(panic = "unwind")]
	fn done(&self, guard: &Guard) {
	if !guard.panicking && thread::panicking() {
	self.failed.store(true, Ordering::Relaxed);
	}
	}

[Person-93]

You're right, the critical section API bypasses it.

[Person-93]

Do you want that as part of this PR? or in a followup?