-
Notifications
You must be signed in to change notification settings - Fork 784
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
Comments
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.
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.
From previous discussions:
Accessing the |
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.
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.
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.
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.
Since you can't access a
Python<'_>
from within__traverse__
, it becomes impossible to access aGILProtected
object while traversing, which causes problems if there is an object that needs to be traversed somewhere inside theGILProtected
. Seeing asGILProtected::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.The text was updated successfully, but these errors were encountered: