Re: Events unsubscribing and resource leaks?
- From: "Bruce Wood" <brucewood@xxxxxxxxxx>
- Date: 29 Sep 2006 16:39:33 -0700
Daniel wrote:
Thanks Bruce very detailed.
If you call an items dispose method, you have forced a dispose?
No, that's not true. Calling Dispose() has nothing to do with garbage
collection. It's intended for freeing non-managed resources as soon as
possible, without having to wait for the GC to reclaim the object (when
the GC will call Dispose itself). By "non-managed" resources I mean
things like Windows file handles, references to (non-.NET) memory your
object may be holding, etc.
Also if you set an item to null you tell the garbage collector to collect
this and free it.
Also not true. There are many threads in this group talking about how
the GC works. Setting a reference variable to null has no effect on
when the GC will reclaim an object, unless the thing being set to null
is a reference from another object, but you would do that as a normal
part of your program's work anyway.
If on doin that it still doesn't reclaim it then that is a different issue
altogether and going into that scope is a bit of overkill.
I know that the weak reference delegate stuff looks like overkill, but
it's better than reference counting, which in some situations is the
only other way. If in your case you always know when your subscribing
objects are no longer needed, and you can unsubscribe from your
singleton's events at that time, then you have no need of either weak
reference delegates or reference counting. In my case I couldn't do
that.
The good news about weak reference delegates is that you write them
once, learn to use them, and then never worry about them again.
I have a singleton in my app that handles my sockets, and so when i receive
certain data over the socket i fire an event to say "Object received" and
then my subscribed receivers here that and react.
I then unsubscribe those instances that are subscribed to that, but the
singleton will remain throughout my app until the final close down where the
singleton is freed and with it the events it created.
That's all fine. It was just that i read a Microsoft article stating that if
the subscribing event is still 'alive' and an instance is subscribed to it,
then the subscribed instance will not be garbage collected, hence you must
unsubscribe then dispose the instance in order to allow garbage collection
and avoid a resource leak. As mine is a singleton this is a must i presume.
Well, you must unsubscribe. Whether you need to Dispose or not depends
entirely upon the subscribing object and whether it's holding any
non-managed resources. Probably not.
But yes, you really have only three choices:
1. Have the client object unsubscribe to the event when it determines
that it's no longer needed. This is the simplest solution but isn't
always practical because it's not always "possible" to determine that.
2. Have the client object count references to itself as a way of
determining if it's no longer needed. I explained why this is
undesirable in my previous post.
3. Use weak reference delegates, which essentially say, "This event
subscription doesn't count as a reference for purposes of garbage
collection."
"To prevent your event handler from being invoked when the event is raised,
simply unsubscribe from the event. In order to prevent resource leaks, it is
important to unsubscribe from events before you dispose of a subscriber
object. " source: http://msdn2.microsoft.com/en-us/library/ms366768.aspx
All true, IF you can determine when your subscriber object is no longer
needed in the context of your program. Sometimes that's very difficult
to do, and weak reference delegates make it unnecessary.
.
- Prev by Date: Source Control - what files should/shouldn't be stored in source control
- Next by Date: Re: Source Control - what files should/shouldn't be stored in source control
- Previous by thread: Source Control - what files should/shouldn't be stored in source control
- Next by thread: Compare unicode string
- Index(es):
Relevant Pages
|
