conversions and #[pyo3(get, set)] for atomic integers

[davidhewitt]

In #4566 we ran into the fact that atomic integers don't currently work as #[pyclass] fields.

We should decide what conversions we want on these types. We can probably implement:

• IntoPyObject and FromPyObject for owned values, because there is no atomic contention in these cases.
• Should we implement IntoPyObject for &AtomicX ? It's not clear to me that we can always just use Relaxed ordering there.
• We should probably specialize the way that #[pyclass(get, set)] work so that Relaxed ordering is used to write #[pyclass] fields. This is probably ok for those uses?

[alex]

I'm a bit concerned that allowing atomics to be converted to Python ints transparently would lead to unexpected behavior with +=

…

On Wed, Oct 30, 2024 at 2:56 AM David Hewitt ***@***.***> wrote: In #4566 <#4566> we ran into the fact that atomic integers don't currently work as #[pyclass] fields. We should decide what conversions we want on these types. We can probably implement: - IntoPyObject and FromPyObject for owned values, because there is no atomic contention in these cases. - Should we implement IntoPyObject for &AtomicX ? It's not clear to me that we can always just use Relaxed ordering there. - We should probably specialize the way that #[pyclass(get, set)] work so that Relaxed ordering is used to write #[pyclass] fields. This is *probably* ok for those uses? — Reply to this email directly, view it on GitHub <#4668>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBCGKTDIZ3TGY6JODZLZ6B7IRAVCNFSM6AAAAABQ3MIR62VHI2DSMVQWIX3LMV43ASLTON2WKOZSGYZDGMBYG43DINI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[ngoldbaum]

Instead of modeling it on the python side using a PyInt we could use a type that represents an explictly atomic fixed-size int.

The ft_utils package from meta defines some python types that wrap atomics (e.g. AtomicInt64). There might be some room for inspiration there.

[davidhewitt]

I'm a bit concerned that allowing atomics to be converted to Python ints transparently would lead to unexpected behavior with +=

Ah, that's a very good point. I think that's reason enough to not support get / set for now (at least not without some kind of upstream support in the interpreter.

Instead of modeling it on the python side using a PyInt we could use a type that represents an explictly atomic fixed-size int.

The ft_utils package from meta defines some python types that wrap atomics (e.g. AtomicInt64). There might be some room for inspiration there.

I'm open to the possibility that we'd need something like this, however quite reluctant. So far we've resisted adding framework-level types in PyO3 (PanicException being the only one); we haven't really found a nice way to expose them for users to import / interact with etc.

[mejrs]

I think we shouldn't support it for now. We can revisit this in the future when the demand arises.