Nathan Goldbaum

>It wouldn't be obvious to me, if I knew nothing, how or why this mutex works. The design is very unlike the mutex in std or parking_lot. > >We should...

> We could probably write a test that it deadlocks by spawning a thread and allowing that thread to deadlock, and can assert that thread doesn't run to completion after...

Thanks for the hint! With the last push I can write a test that deadlocks: ``` #[test] fn test_pymutex_deadlocks() { static MUTEX: OnceLock = OnceLock::new(); static FINISHED: OnceLock = OnceLock::new();...

Thanks for the suggestions! Can you elaborate about what API surface from `std::sync::Mutex` you'd like to see implemented? For example, what about poisoning? > This test should be in its...

While working on something else, I realized just now that rather than creating a new `mutex.rs`, maybe this should live in `sync.rs` along with the other synchronization primitives.

@davidhewitt and I chatted about this today and he convinced me that because PyO3 automatically converts rust panics into Python exceptions, it's actually more important to deal with poisoning, since...

We also decided this doesn't need to block the 0.23 release, since the FFI wrappers also exist.

I'm thinking of finally finishing this off, because Python 3.14 adds `Py_BEGIN_CRITICAL_SECTION_MUTEX` and `Py_BEGIN_CRITICAL_SECTION2_MUTEX`, which accept a `PyMutex *` argument instead of a `PyObject *`. If we add safe rust...

Taking some notes for myself: This is all implemented in the standard library using an `AtomicBool` `Flag` that hangs off the `Mutex` object: https://github.com/rust-lang/rust/blob/246733a3d978de41c5b77b8120ba8f41592df9f1/library/std/src/sync/poison/mutex.rs#L177 And a boolean `guard` that tracks...

@davidhewitt @mejrs does that plan sound reasonable to you?