2

Garbage collected object oriented programming languages reclaim unused memory automatically, but all other kinds of resources (i.e. files, sockets...) still require manual release since finalizers cannot be trusted to run in time (or at all).

Therefore such resource objects usually provide some kind of "close"- or "dispose"-method/pattern, which can be problematic for a number of reasons:

  • Dispose has to be called manually which may pose problems in cases when it is not clear when the resource has to be released (similar problem as with manual memory management)
  • The disposable-pattern is somewhat "viral", since each class containing a disposable resource must be made disposable as well in order to guarantee correct resource cleanup
  • An addition of a disposable member to a class, requiring the class to become disposable as well, changes the interface and the usage patterns of the class, thus breaking encapsulation
  • The disposable-pattern creates problems with inheritance, i.e. when a derived class is disposable, while the base class isn't

So, are there any alternative concepts/approaches for properly releasing such resources? Any papers/research in that direction?

Askaga
  • 6,061
  • 5
  • 25
  • 49
  • The disposable pattern *may* be viral. If you're just using something disposable for a short while, you use `using` or call Dispose. However, if you are keeping around disposable object for the lifetime of your object, yes, you have to implement Dispose and call through. Most of the time, the use of dispose means that the object is supposed to live for a specific period of time, something that fits in with the general interface since it specifies how you're supposed to use it. In that way, it does not break encapsulation. – Jesper Nov 05 '13 at 16:47
  • Are you expecting such an approach to leave the rest of the language relatively unchanged (in particular, would resource-holding objects still be reference types that are aliased indiscriminately and life as long as there are references to them)? In any case, see http://programmers.stackexchange.com/q/216024/7043 –  Nov 26 '13 at 18:34

1 Answers1

-2

One approach (in languages that support it) is to manually trigger a garbage collection event to cause finalizers to run. However, some languages (like Java) do not provide a reliable mechanism for doing so.

Demi
  • 3,535
  • 5
  • 29
  • 45
  • 3
    Leaving aside philosophical objections and assuming the language offers such a facility, this is completely intractible. A full GC would have to run *every single time* a resource *may* have become orphaned, which (without further language changes) would be after every. Freaking. Single. Assignment operation. (As well as exiting a scope and probably some other, rarer cases.) You can't seriously suggest tracing through the entire set of live objects every time one of the most fundamental and common operations is performed? –  Nov 26 '13 at 18:24
  • I don't mean to run a GC after every operation! That would be ridiculous. Rather, run a GC periodically on a timer, or when an attempt to allocate a resource fails (It is usually not needed to close a file handle within a microsecond). – Demi Nov 26 '13 at 22:32
  • But then you don't free resources deterministically or promptly, which is the point of `using`, RAII, and other solutions to the same problem. –  Nov 27 '13 at 14:32
  • Some resources need to be freed relatively soon, but not immediately, as I said above -- promptness is not needed here. – Demi Nov 30 '13 at 02:03