On Thu, Sep 18, 2014 at 4:10 PM, Stefan Richthofer <stefan.richtho...@gmx.de> wrote: >> A quick test (on Mono) says "no", but trying with a class that >> declares __del__ doesn't either, so I'd want to hook up a debugger on >> Windows to check for sure. I'm not sure if the backing types created >> by IronPython have finalizers, but I think not (and reading through >> the RefEmit code will take longer than I have right now.) > > Sounds like IronPython would not support __del__ at all. Is this a basic, > maybe well-known issue or are finalizers principally supported, but currently > broken?
I redid my tests by calling GC.Collect() afterwards, and the "normal" case works just fine, but not the attached case. So yes, they do work. :) > I appended a unit test file and would like to know which of the tests exactly > fail on IronPython. I will surely take the time to test this myself, but it > might > take some days until I come to setting up mono and IronPython. And I thought > you might be interested in these tests too ;-) I'll run the tests when I get a chance on my Windows machine; it might be a better test bed just to eliminate Mono bugs. > > To support acquired finalizers, Jython would have to track all instances for > each class. So it could update them if the class would acquire a finalizer. > Obviously this is insanely expensive for such a rare use-case, so I added a > builtin method __ensure_finalizer__ to Jython, which allows - at least > manually - to fix this. > One can tell already existing instances manually that their class acquired a > finalizer (also works for new style classes): > > class A(): > pass > > def A__del__(): > print "A finalized" > > a1 = A() > A.__del__ = A__del__ > a1.__ensure_finalizer__() > a1 = None But then the end user has to know to run __ensure_finalizer__() on each instance, correct? > > I have only rough knowledge of .net, but believe it behaves somewhat equal to > Java regarding to gc and finalizers. > Since IronPython appears to have equal issues, I would offer guidance and > discussion if you might want to port the Jython approach. > At least I wanted to make you aware of the > __ensure_finalizer__()-method-manual-fix-approach and suggest that if > IronPython would > ever implement an equal method to agree on a common name for it. I thought the .NET GC might store this information already, but no dice. It is available to the profiler API, but that's not really a good way to go about it (unmanaged code, separate DLL, etc.). :) I don't know about the cost of finalization in .NET, although I assume they are similar. Reading about it doesn't seem to be helping much, since it's the sort of thing that's esoteric enough to fall in to cargo-cult land pretty quickly. .NET does have GC.SuppressFinalize that supposedly removes the penalty, but I'm not immediately clear on if that helps in this case. Keeping a set of weak references would solve the problem at a not-too-horrible cost (which I think is what PyPy does, but they can share it with the GC so it's not really overhead). Honestly though, why in the heck would anyone even want to do this? Is there a use case, or is it just matching compatibility with CPython? - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
