3 ms·
I think they make sense for the case of resources that need explicit deallocation, when their lifetime is not tied to a scope (e.g. multiple owners). An exampl
by millstone 11y ago
I think they make sense for the case of resources that need explicit deallocation, when their lifetime is not tied to a scope (e.g. multiple owners).
An example is a Lock object that wraps a pthread_mutex. It's unreasonable to demand that every object that has a lock explicitly dispose of it; it's simpler to equip the Lock with a finalizer that can dispose of the underlying mutex.
- fleitz 11y agoExcept finalizers may not release the mutex if they aren't run
- SamReidHughes 11y agoIt depends whether or not mutexes are "heavy" resources. If making them and not using them is free, then it's OK to treat them like memory and wait for garbage collection to do its thing.
- eel 11y agoIf your application is a well-behaving application in a well-behaving environment, then it will most likely run in a reasonable amount of time. Furthermore, if you leak a few mutexes, it's not really a big deal for most applications. I think one of the implied points of the article is that you should not rely on finalizers for anything time sensitive or critical. For instance, if you MUST close a file handle or database connection, you should never rely on a .NET finalizer to do it because it's not predictable when or if it will run. You should explicitly close it (most likely by implementing and calling Dispose().)