Comments on: Why you should always unscubscribe event handlers

By: Bradley Grainger

Bradley Grainger — Thu, 28 Aug 2008 02:59:51 +0000

Coincidentally, we also recently blogged about unsubscribing from events (http://code.logos.com/blog/2008/08/unsubscribing_from_c_events.html) and how to set up a “weak” subscription (which allows the subscriber to be garbage-collected) to any event, without having to modify the event publisher: http://code.logos.com/blog/2008/08/event_subscription_using_weak_references.html.

By: Interesting Finds: 2008.08.13~2008.08.21 - gOODiDEA.NET

Interesting Finds: 2008.08.13~2008.08.21 - gOODiDEA.NET — Thu, 21 Aug 2008 11:09:35 +0000

[...] Why you should always unscubscribe event handlers [...]

By: Davy Brion

Davy Brion — Wed, 20 Aug 2008 05:34:45 +0000

Not for typical UI scenario’s where the form or the page subscribes to an event of one of the controls that is owned by the form or the page. In that situation, the form/page is the Subscriber and is also the only owner of the Publisher. If the Subscriber is cleaned up, the Publisher automatically goes with it so then there’s no problem. Both instances will be cleaned up without having to explicitely unsubscribe from the events.

If external objects (instances of other classes or other forms or whatever) subscribe to an event of a Form/Page, then you do have to be pretty careful and you should definitely follow the rule.

By: Kiran

Kiran — Wed, 20 Aug 2008 00:27:54 +0000

Does this rule apply in UI scenarios? (WinForms/Asp.Net).

If the answer is yes, do we need to write unsubscription code for every UI element that we subscribe in a form/page? That doesn’t seem normal!

If the answer is No, and if the responsibility of ‘unsubscribing’ is on subscriber, how the asp.net/winforms publishers are cleaning up the bad subscribers?

By: Reflective Perspective - Chris Alcock » The Morning Brew #161

Reflective Perspective - Chris Alcock » The Morning Brew #161 — Tue, 19 Aug 2008 08:09:21 +0000

[...] Why you should always unsubscribe event handlers – Davy Brion talks about one of the most common causes of memory problems caused by the Garbage collector not being able to remove object because other objects still hold references to them via event handlers. [...]

By: Davy Brion

Davy Brion — Tue, 19 Aug 2008 05:22:22 +0000

if it’s not in an interactive scenario (UI stuff), i prefer to use waithandles for async stuff though. But your point is definitely valid… in this case it wouldn’t make sense to unsubscribe from the events

By: David N

David N — Mon, 18 Aug 2008 21:45:12 +0000

Think about an async request that calls back or publishes some ‘completed’ event. Like you said, a somewhat niche case, but still happens enough that it’s a valid (and simplifying) use.

By: Davy Brion

Davy Brion — Mon, 18 Aug 2008 18:45:36 +0000

“Until that change is introduced, letting the objects die is fine.”

If they are all short-lived objects (for instance, to handle some kind of request like you mention) and their life cycle won’t ever change, then yeah, it’s ok. Although i generally never create short-lived Publishers… i’m sure there are scenario’s where it makes sense but in most cases i think it would just make things more ‘complicated’ than they need to be

By: David N

David N — Mon, 18 Aug 2008 18:27:07 +0000

>even if they have the same lifetime, if at some point a change is introduced which extends B’s >lifetime, A will not be cleaned up and it will keep on receiving the event

But that’s the point. Until that change is introduced, letting the objects die is fine. I have a case right now where I’m creating a request object which creates and then passes control to its child objects. No need to deregister listening to their events, bc when it goes they all go.

As always, you have to think about context.

By: David McClelland

David McClelland — Mon, 18 Aug 2008 18:10:23 +0000

That reminds me of Microsoft’s advice back in the .NET 1.x days for avoiding memory leaks when using WinForms data binding: always call [control].DataBindings.Clear()

http://msdn.microsoft.com/en-us/library/ms996446.aspx#databinding_winforms10_11_topic11

Those were the good old days… oh wait! Those days are still here!!!

- David McClelland

By: Davy Brion

Davy Brion — Mon, 18 Aug 2008 17:08:41 +0000

everything that’s static has the possibility to become a pain in the ass

By: Cherian Thomas

Cherian Thomas — Mon, 18 Aug 2008 17:02:55 +0000

Life becomes horrible if its a static event and you don’t follow these practices

By: Davy Brion

Davy Brion — Mon, 18 Aug 2008 16:34:10 +0000

even if they have the same lifetime, if at some point a change is introduced which extends B’s lifetime, A will not be cleaned up and it will keep on receiving the event

By: David N

David N — Mon, 18 Aug 2008 16:26:48 +0000

It depends on the context. If object A is listening to object B, yet they both have the same lifetime (i.e. they die together), you don’t need to deregister any events.

Deregistering is also less trivial when it comes to anonymous delegates.

By: Davy Brion

Davy Brion — Mon, 18 Aug 2008 09:54:35 +0000

That wouldn’t work with regular events, so you’d have to write custom code to get that working and then you’d have to use that ‘non-standard’ mechanism throughout your code base

at that point it’s probably easier to just make sure each subscriber offers a way to unsubscribe from the events

By: Cherian Thomas

Cherian Thomas — Mon, 18 Aug 2008 08:42:35 +0000

Do you think it’s wise to make the subscriber register a weak reference?