-
Notifications
You must be signed in to change notification settings - Fork 776
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
conversions and #[pyo3(get, set)]
for atomic integers
#4668
Comments
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.
|
Instead of modeling it on the python side using a The ft_utils package from meta defines some python types that wrap atomics (e.g. |
Ah, that's a very good point. I think that's reason enough to not support
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 ( |
I think we shouldn't support it for now. We can revisit this in the future when the demand arises. |
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
andFromPyObject
for owned values, because there is no atomic contention in these cases.IntoPyObject for &AtomicX
? It's not clear to me that we can always just useRelaxed
ordering there.#[pyclass(get, set)]
work so thatRelaxed
ordering is used to write#[pyclass]
fields. This is probably ok for those uses?The text was updated successfully, but these errors were encountered: