3 ms·
The cache will hold references to every single item and the GC will never be able to destroy them, that is, unless the cache goes out of scope Had the reverse
by stinos 10y ago
The cache will hold references to every single item and the GC will never be able to destroy them, that is, unless the cache goes out of scope
Had the reverse happening a while ago and it's nasty as well: some C++ objects were holding references to a Python objects, but due to the GC not scanning those memory regions (they're not Python-owned after all), the Python objetcs would get GC'd and all hell broke loose when the C++ tried to access the now dead Python objects. Solution is forced 'lingering', i.e. is applying some RAII adding the Python objects to a global dict and removing them when the C++ objects go out of scope.
- kevin_thibedeau 10y agoShouldn't the C++ notify Python of the extra references by incrementing the ref counts?
- winstonewert 10y agoUgh... No. That's not how Python's GC works. Python is reference counted. This was happening because you didn't increment the reference count for python objects you were referencing from C++. Your RAII should increment/decrement reference counts on the object, not place objects into a global dict. That's the "correct" way to reference python objects. Python's GC doesn't scan memory in the same way other languages do. Instead, it detects cycles between python objects. As long as you follow the reference counting rules correctly, you shouldn't have to worry about it. (Unless you need to detect cycles involving your C++ objects.)
- stinos 10y agoUgh... No. That's not how Python's GC works. You assume CPython, or some other reference counted implementation though. I'm talking about MicroPython which uses mark&sweep. And which I obviously should have mentioned but I guess I was tired and I didn't.