views:

1451

answers:

6

Is it a good practice to implement event handling through WeakReference if that event is the only thing holding the reference and that we would need the object to be garbage collected?

As an argument to this:

Folks say that if you subscribe to something it’s your responsibility to unsubscribe and you should do it.

A: 

While what you suggest solves one set of problems (event reference management and memory leak prevention), it is likely to open up a new set of problems.

One problem I can see is during event handling process if the source object is garbage collected (as it was only held with a weak reference), any code that access the source object will result in null reference exception. You can argue that the event handler should either not access the source object or it must have a strong reference, but it can be argued that this could be a worse problem than the one you are trying to solve in the first place.

Samuel Kim
When CLR already executes event handler, stack will hold reference to "this" and objects will not be collected.
Ilya Ryzhenkov
+2  A: 

Weak delegate pattern is something that should be there in CLR. Normal events exhibit "notify me while you are alive" semantics, while often we need "notify me while I'm alive". Just having delegate on WeakReference is wrong, because delegate is an object too and even when recepient is still alive and have incoming references, delegate itself is only being referenced by said WeakReference and will be collected instantly. See this old post for an example of implementation.

Ilya Ryzhenkov
+1  A: 

Weak references in their own right, don't solve the problem as the delegate holds the reference. In the Composite Application Library which ships with Prism (www.microsoft.com/compositewpf) there is a WeakDelegate class that you could pull from the source. The WeakDelegate basically ues reflection and creates a delegate only for a moment in time and then releases it, thereby no holding any pointers. Within CAL it is used by the EventAggregator class, but you are free to rip it out for your own usage as it is under MS-PL.

Glenn Block
+1  A: 

You can take a look at how this problem is approached in WPF here:
http://msdn.microsoft.com/en-us/library/aa970850.aspx

siz
+5  A: 

It is good to get in the habit of unsubscribing from events when you can, but sometimes there isn't an obvious "cleanup" method where it can be done. We recently posted a blog article on this subject; it includes methods that make it easy to subscribe to an event with a WeakReference.

Ed Ball
+1  A: 

I found another quite nice implementation here:

http://diditwith.net/2007/03/23/SolvingTheProblemWithEventsWeakEventHandlers.aspx

Gluip
very nice resource
Andrew Garrison