Explicitly call IDispose() method
-
Hello all, Does anyone know if the Dispose() method must be explicity called on every object that implements IDispose? In other words, will the Garbage collector call the Dispose() method when the object's life expires. Don't get me wrong, I know that it's good practice to clean up your own trash but I didn't know how serious of a memory leak this issue is. In addition to that, what about un-wiring event handlers from a class before it's reference is set to null? I've code that removes handlers and code that doesn't. Any thoughts?
The hurrier I go, the behinder I get.
-
Hello all, Does anyone know if the Dispose() method must be explicity called on every object that implements IDispose? In other words, will the Garbage collector call the Dispose() method when the object's life expires. Don't get me wrong, I know that it's good practice to clean up your own trash but I didn't know how serious of a memory leak this issue is. In addition to that, what about un-wiring event handlers from a class before it's reference is set to null? I've code that removes handlers and code that doesn't. Any thoughts?
The hurrier I go, the behinder I get.
Hi, this is how I understand it: 1. you should call Dispose(), it makes life easier for the GC, and it frees resources sooner. 2. Managed objects that die will be disposed by GC if and when it runs; it does not run when no more memory requests are needing a garbage collection, and in particular when an app terminates. 3. you must make sure Dispose() is called when unmanaged objects are involved. 4. you don't know (unless it is documented) whether managed classes create unmanaged objects internally, so call Dispose! 5. A process exiting will clean up everything, which does not imply your resources will be in a state you like; e.g. a process will close its open files, it may not have written the closing texts to it if you don't take care. 6. When you hand over a delegate, it includes a "this" pointing to the object on which the delegate is to be called. So passing a delegate to a live object keeps your object alive too. But not the other way around, so it is no problem most of the times. Example1: your class instantiates a dialog and passes a delegate to one of the dialog buttons; the dialog keeps your class alive, but it was modal anyway. When the dialog closes, it gets disposed and the delegates are gone. Example2: your form passes a delegate to an object (maybe a singleton) that lives for the life of your app, e.g. to get signaled when a logging component gets a problem, say a disk full condition. When you close your form, it remains alive because of the delegate. If all your forms do this, none of them ever releases its memory. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi, this is how I understand it: 1. you should call Dispose(), it makes life easier for the GC, and it frees resources sooner. 2. Managed objects that die will be disposed by GC if and when it runs; it does not run when no more memory requests are needing a garbage collection, and in particular when an app terminates. 3. you must make sure Dispose() is called when unmanaged objects are involved. 4. you don't know (unless it is documented) whether managed classes create unmanaged objects internally, so call Dispose! 5. A process exiting will clean up everything, which does not imply your resources will be in a state you like; e.g. a process will close its open files, it may not have written the closing texts to it if you don't take care. 6. When you hand over a delegate, it includes a "this" pointing to the object on which the delegate is to be called. So passing a delegate to a live object keeps your object alive too. But not the other way around, so it is no problem most of the times. Example1: your class instantiates a dialog and passes a delegate to one of the dialog buttons; the dialog keeps your class alive, but it was modal anyway. When the dialog closes, it gets disposed and the delegates are gone. Example2: your form passes a delegate to an object (maybe a singleton) that lives for the life of your app, e.g. to get signaled when a logging component gets a problem, say a disk full condition. When you close your form, it remains alive because of the delegate. If all your forms do this, none of them ever releases its memory. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Thanks Luc! I agree that just because some class is managed, doesn't mean that it will not call unmanaged code. (Good point) You've definitely cleared up some question marks in my brain!
The hurrier I go, the behinder I get.
-
Hello all, Does anyone know if the Dispose() method must be explicity called on every object that implements IDispose? In other words, will the Garbage collector call the Dispose() method when the object's life expires. Don't get me wrong, I know that it's good practice to clean up your own trash but I didn't know how serious of a memory leak this issue is. In addition to that, what about un-wiring event handlers from a class before it's reference is set to null? I've code that removes handlers and code that doesn't. Any thoughts?
The hurrier I go, the behinder I get.
Richard Blythe wrote:
what about un-wiring event handlers from a class before it's reference is set to null? I've code that removes handlers and code that doesn't.
AFAIK, you don't have to unwire each event. Setting it to
nullwill remove the invocation list.Navaneeth How to use google | Ask smart questions
-
Hello all, Does anyone know if the Dispose() method must be explicity called on every object that implements IDispose? In other words, will the Garbage collector call the Dispose() method when the object's life expires. Don't get me wrong, I know that it's good practice to clean up your own trash but I didn't know how serious of a memory leak this issue is. In addition to that, what about un-wiring event handlers from a class before it's reference is set to null? I've code that removes handlers and code that doesn't. Any thoughts?
The hurrier I go, the behinder I get.
As far as I'm concerned, the definitive article on finalizers and disposable objects can be found over on Joe Duffy's Blog[^].
"we must lose precision to make significant statements about complex systems." -deKorvin on uncertainty
-
Richard Blythe wrote:
what about un-wiring event handlers from a class before it's reference is set to null? I've code that removes handlers and code that doesn't.
AFAIK, you don't have to unwire each event. Setting it to
nullwill remove the invocation list.Navaneeth How to use google | Ask smart questions
However, if consumer1 and consumer2 both wire to some event in producer3, and only consumer1 wants to exit the game, then noone is allowed to set the event to null since that would break the producer3-consumer2 relation. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
As far as I'm concerned, the definitive article on finalizers and disposable objects can be found over on Joe Duffy's Blog[^].
"we must lose precision to make significant statements about complex systems." -deKorvin on uncertainty
I absolutely disagree with the "Dispose(bool)" pattern. It's verbose and hard to use correctly. And it's only really useful when a class contains both managed and unmanaged resources, and there might even be derived classes that have their own unmanaged resources. The solution is simple: don't do that. Instead, create a sealed class for each unmanaged resource (bonus points if its derived from SafeHandle). Then your other classes only have to deal with managed resources, so they never need a finalizer and the Dispose method is trivial (just call Dispose on all members). For more details, take a look at Stephen Cleary's article 'IDisposable: What Your Mother Never Told You About Resource Deallocation'[^].
-
However, if consumer1 and consumer2 both wire to some event in producer3, and only consumer1 wants to exit the game, then noone is allowed to set the event to null since that would break the producer3-consumer2 relation. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
Yeah. That's right :)
Navaneeth How to use google | Ask smart questions