[IronPython] Event unhooking and IPy2

Michael Foord fuzzyman at voidspace.org.uk
Tue Dec 2 21:14:29 CET 2008


Dino Viehland wrote:
> We don't always remember what we've wired up though.  If you give us a delegate which matches the type exactly we'll just go ahead and hook it up (to avoid adding an extra level of indirection).  Only if you give us some random callable object will we remember it.  It'd be easy enough for us to remember but I wonder if this is really a good idea.
>
>   
That sounds fair enough.

> What if someone else has subscribed to the event?  If you have the ability to clear the events then you could cause someone elses subscription to go away.  Maybe you "know" that no one else will have subscribed but it does seem like this breaks the encapsulation of events.
>
>   

Well, in our case it is when we want to dispose of UI elements - so 
anything listening *must* unsubscribe.

> I do think we have the event leaks fixed (we hold no strong references at all now).  To trackl down leaks here I'd suggest using windbg & SOS to track down the remaining references.  You can !DumpHeap to list the entire heap, find the object type you think is keeping everything alive, and then do !GCRoot on its address and see who's keeping it alive.
>
>   

This is what we do - and great fun it is too. :-)

Michael

> Alternately you could use the weak event pattern.
>
>   
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-
>> bounces at lists.ironpython.com] On Behalf Of Michael Foord
>> Sent: Tuesday, December 02, 2008 11:49 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Event unhooking and IPy2
>>
>> Marty Nelson wrote:
>>     
>>> We've had probably with memory leaks on Windows Form subscribed menu
>>> item clicks, just with plain vanilla C#.
>>>
>>>
>>>       
>> Ok - it may well not be the fault of IronPython. (Certainly some event
>> handlers don't cause us problems whilst others do). On the other hand,
>> as IronPython *is* keeping track of all the handlers we add, an easy
>> interface to unhook them all would be extremely useful.
>>
>> Michael Foord
>>
>>     
>>> Check out this link http://www.bobpowell.net/eventsubscribers.htm
>>>       
>> (There
>>     
>>> are some additional steps for System.Windows.Forms.Component), and
>>> here's some sample code I wrote in C# that you could leverage:
>>>
>>>     [TestClass]
>>>     public class UnhookEventsTests
>>>     {
>>>         private class Item
>>>         {
>>>             public event EventHandler Clicked;
>>>
>>>             public void FireEvent()
>>>             {
>>>                 if(Clicked != null)
>>>                 {
>>>                     Clicked(this, EventArgs.Empty);
>>>                 }
>>>             }
>>>         }
>>>
>>>         [TestMethod]
>>>         public void UnhookEvents()
>>>         {
>>>             Item item = new Item();
>>>             item.Clicked += Clicked;
>>>             item.Clicked += Clicked2;
>>>
>>>             item.FireEvent();
>>>
>>>             Assert.AreEqual(2, callCount_);
>>>
>>>             FieldInfo field = typeof (Item).GetField("Clicked",
>>> BindingFlags.NonPublic | BindingFlags.Instance);
>>>             Delegate del = (Delegate) field.GetValue(item);
>>>             Delegate[] list = del.GetInvocationList();
>>>
>>>             Assert.AreEqual(2, list.Length);
>>>
>>>             //This works:
>>>             //foreach (Delegate d in list)
>>>             //{
>>>             //    item.Clicked -= (EventHandler) d;
>>>             //}
>>>
>>>             //This is more generic and avoids the cast to the
>>>       
>> specific
>>     
>>> handler type
>>>             EventInfo eventInfo = typeof (Item).GetEvent("Clicked");
>>>             foreach (Delegate d in list)
>>>             {
>>>                 eventInfo.RemoveEventHandler(item, d);
>>>             }
>>>
>>>             item.FireEvent();
>>>
>>>             Assert.AreEqual(2, callCount_);
>>>         }
>>>         private int callCount_;
>>>         private void Clicked(object sender, EventArgs e)
>>>         {
>>>             callCount_++;
>>>         }
>>>
>>>         private void Clicked2(object sender, EventArgs e)
>>>         {
>>>             callCount_++;
>>>         }
>>>     }
>>>
>>> -----Original Message-----
>>> From: users-bounces at lists.ironpython.com
>>> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil
>>> Dworakowski
>>> Sent: Saturday, November 29, 2008 1:16 PM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Event unhooking and IPy2
>>>
>>> On Fri, Nov 28, 2008 at 11:39 AM, Michael Foord
>>> <fuzzyman at voidspace.org.uk> wrote:
>>>
>>>       
>>>> Just as a follow up to this - the reason for the hack below is that
>>>> subscribing to events from IronPython is still causing our UI
>>>>         
>> objects
>>     
>>> (and
>>>
>>>       
>>>> their whole object graphs) to not be garbage collected.
>>>>
>>>>         
>>> To be fair, we have no reason to belive it is IronPython's fault. The
>>> bug that event handlers would prevent garbage collection was fixed,
>>> and we were able to remove *some* of the event nuking.
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>> =======
>>> Notice: This e-mail message, together with any attachments, contains
>>> information of Symyx Technologies, Inc. or any of its affiliates or
>>> subsidiaries that may be confidential, proprietary, copyrighted,
>>> privileged and/or protected work product, and is meant solely for
>>> the intended recipient. If you are not the intended recipient, and
>>> have received this message in error, please contact the sender
>>> immediately, permanently delete the original and any copies of this
>>> email and any attachments thereto.
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>       
>> --
>> http://www.ironpythoninaction.com/
>> http://www.voidspace.org.uk/blog
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>     
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog





More information about the Ironpython-users mailing list