Skip to content
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

Access GILProtected via PyVisit #3615

Closed
neachdainn opened this issue Nov 30, 2023 · 1 comment · Fixed by #3616
Closed

Access GILProtected via PyVisit #3615

neachdainn opened this issue Nov 30, 2023 · 1 comment · Fixed by #3616

Comments

@neachdainn
Copy link
Contributor

Since you can't access a Python<'_> from within __traverse__, it becomes impossible to access a GILProtected object while traversing, which causes problems if there is an object that needs to be traversed somewhere inside the GILProtected. Seeing as GILProtected::get doesn't actually do anything, this should be a valid operation despite the restrictions imposed during GC.

Rather than rehashing the discussions from previous issues regarding marker access during GC, it seems relatively straight-forward to simply allow access to the inner object using a PyVisit object.

neachdainn added a commit to neachdainn/pyo3 that referenced this issue Nov 30, 2023
Closes PyO3#3615

This simply adds a new method which uses the existence of a `PyVisit`
object as proof that the GIL is held instead of a `Python` object. This
allows `GILProtected` to be used in instances where contained Python
objects need to participate in garbage collection. Usage in this
situation should be valid since no Python calls are made and this does
not provide any additional mechanism for accessing a `Python` object.
neachdainn added a commit to neachdainn/pyo3 that referenced this issue Nov 30, 2023
Closes PyO3#3615

This simply adds a new method which uses the existence of a `PyVisit`
object as proof that the GIL is held instead of a `Python` object. This
allows `GILProtected` to be used in instances where contained Python
objects need to participate in garbage collection. Usage in this
situation should be valid since no Python calls are made and this does
not provide any additional mechanism for accessing a `Python` object.
@neachdainn
Copy link
Contributor Author

From previous discussions:

I believe you can still borrow PyCell from traverse. We can't use the GIL, but we can still make use of the fact that there is at most one thread with the GIL.

The problem is that PyCell derefs into PyAny which provides implicit access to a GIL token via PyAny::py, i.e. we cannot even expose &PyCell<Self> or any &PyAny to the traverse implementation if it is not supposed to safely assume holding the GIL.

Accessing the GILProtected object can make use of the fact that there is at most one thread with the GIL while also not providing any new access to a GIL token.

neachdainn added a commit to neachdainn/pyo3 that referenced this issue Nov 30, 2023
Closes PyO3#3615

This simply adds a new method which uses the existence of a `PyVisit`
object as proof that the GIL is held instead of a `Python` object. This
allows `GILProtected` to be used in instances where contained Python
objects need to participate in garbage collection. Usage in this
situation should be valid since no Python calls are made and this does
not provide any additional mechanism for accessing a `Python` object.
neachdainn added a commit to neachdainn/pyo3 that referenced this issue Dec 5, 2023
Closes PyO3#3615

This simply adds a new method which uses the existence of a `PyVisit`
object as proof that the GIL is held instead of a `Python` object. This
allows `GILProtected` to be used in instances where contained Python
objects need to participate in garbage collection. Usage in this
situation should be valid since no Python calls are made and this does
not provide any additional mechanism for accessing a `Python` object.
neachdainn added a commit to neachdainn/pyo3 that referenced this issue Dec 5, 2023
Closes PyO3#3615

This simply adds a new method which uses the existence of a `PyVisit`
object as proof that the GIL is held instead of a `Python` object. This
allows `GILProtected` to be used in instances where contained Python
objects need to participate in garbage collection. Usage in this
situation should be valid since no Python calls are made and this does
not provide any additional mechanism for accessing a `Python` object.
davidhewitt pushed a commit that referenced this issue Dec 29, 2023
Closes #3615

This simply adds a new method which uses the existence of a `PyVisit`
object as proof that the GIL is held instead of a `Python` object. This
allows `GILProtected` to be used in instances where contained Python
objects need to participate in garbage collection. Usage in this
situation should be valid since no Python calls are made and this does
not provide any additional mechanism for accessing a `Python` object.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant