⚠️ Does `PyClassGuard<T>` require `T: Sync`?

[davidhewitt]

Reading PyClassGuard<T> code just now, I think that PyClassGuard needs to require T: Sync - it allows access from multiple reader threads at the same time.

most #[pyclass] types have this enforced (since #4566), unless they're #[pyclass(unsendable)]. If they're unsendable, the guard code prevents access from multiple threads.

So even though the bound is not enforced in the type system, it's enforced in practice by the macros.

So I think we're ok, but we seem to be treading on thin ice. Does this imply we need to re-think?

[Icxolu]

You mean unconditionally, because there could be multiple Python threads all calling into Rust which then all have access to &T? I think you're right, we should require this.

[Icxolu]

I believe PyRef then has the same problem, at least on the free-threaded build, right? We could also borrow it from two threads even if the T would not by Sync.

[davidhewitt]

Yes. I think we're ok because #[pyclass] requires Sync since #4566, but if we ever modify that bound in the future these abstractions all fall apart.

However I think we can't unconditionally require Sync as long as we have #[pyclass(unsendable)] 🤔

[Icxolu]

Should we perhaps start deprecating unsendable, so that we can require it in the future? It always felt quite hacky to me and with free-threading its usefulness seems questionable.

[davidhewitt]

I'm unsure, I agree that the general Python ecosystem is heading towards multithreaded code and unsendable seems hard to justify in that context.

unsendable also has flaws which are seemingly unavoidable with free-threaded Python, such as the GC always runs in a separate thread so will move all data involved in cycles. Our solution here is to leak unsendable data involved in GC.

The response I kept seeing to justify unsendable is that there are use cases for !Send and !Sync types to be wrapped in Python for specialist local applications (e.g. mathematical simulations).

I wonder if there is a way we can restructure the feature so we can move unsendable out of the macros and more into user code, e.g. with a newtype wrapper. Potentially even out of the PyO3 main crate into a utils crate. IMO it's a power user feature which users should not unknowingly reach for.

[Cheukting]

IMO it's a power user feature which users should not unknowingly reach for.

Totally agree with that. @davidhewitt is there any testing right now I can help with? Like testing with thread-free Python.