Greg Ewing <greg@cosc.canterbury.ac.nz> writes: > What bothers me, though, is that even with finalizers, the library > writer *still* can't guarantee eventual reclamation. The application > can unwittingly stuff it all up by creating cycles, and there's > nothing the library writer can do about it. That is not so. If the object having a finalizer doesn't support references to arbitrary other objects, then the application cannot make this object be part of a cycle. This is while file objects will be eventually closed: they cannot be part of a cycle. Being-referred-to from a cycle is fine: If the cycle itself has no objects with finalizers, GC will break the cycle at an arbitrary point and thus release all objects in the cycle, which will then release the object with a finalizer, which will run the finalizer. So my usage guideline is this: If you need a finalizer, always make two objects. One carries the resource being encapsulated, and nothing else. The other one is the object exposed to applications, which has a reference to the resource. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4