Should investigate usage of py::wraper<> trampoline shim with GC garbage collection (to prevent inheritance slicing) #2757
Description
Motivation
Towards #1333 (as part of the larger umbrella of #2646), this is meant to be my recording of investigating a py::wrapper<> shim trampoline with "resurrection" via the Python garbage collection.
Proof of Concept
I have a working proof-of-concept that is used for in a fork of pybind11 - see RobotLocomotion/pybind11:README_DRAKE.md.
The primary points to see are:
- Resurrection via GC:
py::wrapper<> - Additional mechanisms for holder ownership transfer to/from C++:
py::class_<> methods(note: some of this is coupled to other issues mentioned in the fork README - Tests:
test_ownership_transfer.py,test_ownership_transfer.cpp
Drawbacks
- This approach is a bit messy, as it's from me "just making" things work for our library (Drake).
- As shown above, CPython 3.8 (and possibly 3.7.5+), we are unable to resurrect an object more than once.
Additional Notes
This may not be the best mechanism to prevent slicing. Willi be listing other mechanisms (i.e. PRs / suggestions from others).
External References
- CPython Object Model -
object.__del__ - CPython Developer Guide - Additional Resources
- CPython issue tracker
- Issue 40240 - Expose (read-only) GC info
- Issue 32377 - CPython 3.x GC ressurection got more picky