If I remember correctly we can't just directly hook the events the 'normal' way 
because then the unhook fails in certain cases.  But it looks like we still 
have some bugs related to that anyway.  I tracked down the original bug and the 
way this came about was we had code like:

>>> class C:
...     def cf(self, x):
...             print "inside C.F"
...             return x
...
>>> r = IronPythonTest.ReturnTypes()
>>> c = C()
>>> r.floatEvent += c.cf
>>> r.RunFloat(20)
inside C.F
20.0
>>> r.floatEvent -= c.cf
>>> r.RunFloat(20)
inside C.F
20.0

And before 1.0 beta 3 this was broken.  I fixed it by using the WeakHash class. 
The reason why the above code was broken is because the CLR only does object 
equality comparisons when unhooking delegates.  And each time we have a 
delegate to 'c.cf' we have a new ReflectedMethod which is bound to the instance 
- and therefore the instances don't compare as equal and the CLR doesn't think 
the delegates are the same.  Unfortunately we still seem to have some other 
bugs on CodePlex related to event hooking so I'm guessing this gets another 
pass before 2.0 is done.

I've gone ahead and opened bug #14454 to track it 
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14454.

Also, when it comes to WeakHash we actually are aware of this problem in 
general although we hadn't yet seen it creep into IronPython.  We knew it'd be 
an issue for IronRuby where we have to use the weak hash table much more 
because you can add to arbitrary objects.  We're trying to get some support 
from the CLR to make this work correctly.  So solving the general problem might 
take a while but hopefully we'll get a chance to at least revisit the event 
handling code.

Thanks for the bug report!

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamil Dworakowski
Sent: Tuesday, December 18, 2007 6:26 AM
To: [email protected]
Subject: Re: [IronPython] static source2handler mapping causing memory leaks

Why not make values of the mapping weak references too?

Weak ref for value is bad because that would allow the handler to be garbage 
collected even though the sender is alive. That problem is harder than I 
thought initially.

Why not store the subscribers on a list attached to the source object?

--
Kamil Dworakowski


_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to