This is like a MemoryLeak
, but instead of being memory the resource that is not accessible and that is wasted, is another OperatingSystem
resource, like file handles, semaphores, sockets, etc.
In client software, this is not usually a problem since the program will end in a few minutes and most OperatingSystem
s recover the missing resources that the ended application forgot to return.
In server software, this is usually the reason for the server to be restarted after several hours, because otherwise the OperatingSystem
becomes out of resources.
A typical way to avoid ResourceLeak
s in C++ is to return all resources in destructors using the ResourceAcquisitionIsInitialization
idiom, while in Java it is to use the try-finally block.
A typical solution for server software is that after any request has been serviced, all resources associated to that request are freed. -- GuillermoSchwarz
That is like saying that you solve the problem of memory leaks by freeing all allocated memory when you are done with it. I don't think anyone sits down with the deliberate intention of not freeing resources when usage is completed. -- AnonymousDonor
Usually you should return resources as soon as you are done with them. This is easy, but also it is easy that somebody else comes later, modifies the methods and you have ResourceLeaks?
in your program, either for every request or for special circumstances. In those cases it helps to avoid asking for resources directly, but you better use a helper that registers everything you have asked for for the current request. Then when the request is done, the controller asks the helper to return all resources that you forgot to return. -- GuillermoSchwarz
The problem is that you don't always know which resources are being used. We strive to hide the details of resource use from higher-level abstractions, and in doing so we create situations where resources can be allocated without being freed.
One difference between memory and other OS resources (files, semaphores, processes) is that it is far
easier to run out of the latter than the former.