When interfacing to external systems (a database, a graphics subsystem, a file system, whatever) we often get handles that correspond to resources on these systems, which we are responsible for releasing when we're done. How do we ensure this happens?
-
C++ users are used to explicitly marking their objects dead using the "delete" operator. This will cause the objects destructor to get called, so external resources that it owns can be released there. See ResourceAcquisitionIsInitialization
-
Users of GCed languages don't have to do this as much, because the most common resource that their objects are using is memory, and the memory will usually be released as soon as its needed for some other purpose. In some languages, a finalizer (roughly equivalent to a destructor) will be called when the GC notices that the object is no longer needed; however, the GC may only run when memory is low, so many languages with GarbageCollection make no promises about how long a time elapses between the last known use of an object and when it's finalized. If holding onto the external resource has user-visible action (e.g. it makes a window disappear) or there are a limited number of such resources, some explicit call is still needed to tell the object to release its external resource. Presently on Wiki this is dealt with in
-
ReleasingResourcesInJava (use finalizers and call System.gc() a lot, or use try/finally, or inner classes
-
ResourceReleasesResource : make an object responsible for the resource and have clients register with it
-
ResourceAcquisitionIsInvocation (language-independent, uses closures in the same way as the inner class suggestion above)
-
Contributions at the bottom of ProducingSingletonGarbage describing the standard idiom in Lisp
-
WhenDoesAnObjectBecomeGarbage - interesting ThreadMode stuff
-