Python's weak reference support includes the ability to deliver a callback when the object is finalized. That differs from .NET's weak reference support where at best you can poll the weak reference object to find out if the object has gone away. Luckily in Python objects need to opt-in to support weak reference tracking (for example you can't create a weak reference to an int). So to fully support Python's weak reference semantics we have an interface IWeakReferencable which is implemented on Python objects which support weak references. Weak referencable objects all have an extra field (or somewhere) they can store the WeakRefTracker so it's lifetime matches the objects lifetime. Once the object is eligible for collection the weak ref tracker's will also have no other references so it's finalizer will be run, and any weak ref callbacks can then be delivered.
In general WeakRefTracker's should be created lazily - that is someone should be explicitly creating a weak ref to some object. If there's a lot of weak ref's happening then it's not too surprising that the finalizers could take some while to complete. OTOH there could be something odd going on w/ objects being resurrected and maybe having their finalizers running repeatedly (I don't quite remember what happens with finalizable objects when they're resurrected, so maybe this won't happen). Or maybe they're just not being created lazily in some case now. Or maybe the callback is actually doing a lot of work and that's where the CPU time is going. From: Ironpython-users [mailto:ironpython-users-bounces+dinov=exchange.microsoft....@python.org] On Behalf Of Markus Schaber Sent: Tuesday, October 23, 2012 7:56 AM To: Discussion of IronPython Subject: [Ironpython-users] WeakRef'tracker Hi, What's the purpose of IronPython.Rumtime.WeakRefTracker? I did run the attached program (which is similar to the example for http://ironpython.codeplex.com/workitem/31764). After running a bunch of scripts, the program calls GC.Collect() and GC.WaitForPendingFinalizers() several times. At that moment, the code does not hold any reference to any IronPython or Scripting related objects, so I'd expect everything to be cleaned up by the GC. Despite that fact, I found out that the program spends several seconds with 100% CPU load after returning from the Main() method. When Breaking it in the Debugger several times, it did always end up in the Finalizer method of the WeakRefTracker, so my guess is that most of those several seconds are spent there. Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com<mailto:m.scha...@3s-software.com> | Web: http://www.3s-software.com <http://www.3s-software.com/> CoDeSys internet forum: http://forum.3s-software.com<http://forum-en.3s-software.com/> Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
