Comments on: Why you should always unscubscribe event handlers http://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/ inquisitive: adjective. given to inquiry, research, or asking questions; eager for knowledge; intellectually curious Sun, 20 May 2012 21:55:00 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Bradley Graingerhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1462 Bradley Grainger Thu, 28 Aug 2008 02:59:51 +0000 http://davybrion.com/blog/?p=325#comment-1462 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. 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.NEThttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1312 Interesting Finds: 2008.08.13~2008.08.21 - gOODiDEA.NET Thu, 21 Aug 2008 11:09:35 +0000 http://davybrion.com/blog/?p=325#comment-1312 [...] Why you should always unscubscribe event handlers [...] [...] Why you should always unscubscribe event handlers [...]

]]> By: Davy Brionhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1284 Davy Brion Wed, 20 Aug 2008 05:34:45 +0000 http://davybrion.com/blog/?p=325#comment-1284 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. 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: Kiranhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1280 Kiran Wed, 20 Aug 2008 00:27:54 +0000 http://davybrion.com/blog/?p=325#comment-1280 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? 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 #161http://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1262 Reflective Perspective - Chris Alcock » The Morning Brew #161 Tue, 19 Aug 2008 08:09:21 +0000 http://davybrion.com/blog/?p=325#comment-1262 [...] 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. [...] [...] 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 Brionhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1256 Davy Brion Tue, 19 Aug 2008 05:22:22 +0000 http://davybrion.com/blog/?p=325#comment-1256 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 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 Nhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1243 David N Mon, 18 Aug 2008 21:45:12 +0000 http://davybrion.com/blog/?p=325#comment-1243 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. 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 Brionhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1237 Davy Brion Mon, 18 Aug 2008 18:45:36 +0000 http://davybrion.com/blog/?p=325#comment-1237 "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 “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 Nhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1236 David N Mon, 18 Aug 2008 18:27:07 +0000 http://davybrion.com/blog/?p=325#comment-1236 >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 eventBut 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. >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 McClellandhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1235 David McClelland Mon, 18 Aug 2008 18:10:23 +0000 http://davybrion.com/blog/?p=325#comment-1235 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_topic11Those were the good old days... oh wait! Those days are still here!!!:-)- David McClelland 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 Brionhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1229 Davy Brion Mon, 18 Aug 2008 17:08:41 +0000 http://davybrion.com/blog/?p=325#comment-1229 everything that's static has the possibility to become a pain in the ass ;) everything that’s static has the possibility to become a pain in the ass ;)

]]> By: Cherian Thomashttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1228 Cherian Thomas Mon, 18 Aug 2008 17:02:55 +0000 http://davybrion.com/blog/?p=325#comment-1228 Life becomes horrible if its a static event and you don't follow these practices :-) Life becomes horrible if its a static event and you don’t follow these practices :-)

]]> By: Davy Brionhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1227 Davy Brion Mon, 18 Aug 2008 16:34:10 +0000 http://davybrion.com/blog/?p=325#comment-1227 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 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 Nhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1226 David N Mon, 18 Aug 2008 16:26:48 +0000 http://davybrion.com/blog/?p=325#comment-1226 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. 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 Brionhttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1218 Davy Brion Mon, 18 Aug 2008 09:54:35 +0000 http://davybrion.com/blog/?p=325#comment-1218 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 baseat that point it's probably easier to just make sure each subscriber offers a way to unsubscribe from the events 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 Thomashttp://davybrion.com/blog/2008/08/why-you-should-always-unscubscribe-event-handlers/comment-page-1/#comment-1212 Cherian Thomas Mon, 18 Aug 2008 08:42:35 +0000 http://davybrion.com/blog/?p=325#comment-1212 Do you think it’s wise to make the subscriber register a weak reference? Do you think it’s wise to make the subscriber register a weak reference?

]]>