Hi, Jeff, Von: Jeff Hardy
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. > :) And I just wanted to write a mail and ask whether you made sure that the GC actually kicks in when reading your first mail - it's good I did hesitate and read the whole thread :-) The asynchrony and non-deterministic nature of the .NET and Java GCs are one of the biggest difference to cPython, this especially gets visible with "unclean" code which relies on the reference counting to release resources (like files). [...] > > 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.). :) Sadly, not even the performance counters provide that numbers: http://msdn.microsoft.com/en-us/library/x2tyfybc%28v=vs.110%29.aspx I also agree that the profiling API is not a good way just to get this metadata. > 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). I think weak references are not worth that effort. > 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? I guess it's just interesting for debug code. Best regards Markus Schaber CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
