good article, esp. the "The trouble with Finalizers" part

2011/1/10 ron_m <ron.mco...@gmail.com>:
> In the sample code if one comments out the __del__ method in the class the
> leak does not occur. That is not to say it can't happen I suppose in a more
> complicated code example but I believe the __del__ is a required piece. This
> test was performed without the gc.collect() being present. I ran System
> Monitor on Ubuntu and watched the python process after each edit and
> monitored memory size to verify. So the only way I got the leak was to have
> the __del__method present on the class in the exec example and not have the
> gc.collect() call.
>
> I left the process running with the leak (__del__ present in class and
> gc.collect() commented out) and it got to 3 GB of process space so the
> collector never ran. The system was showing all the signs of a machine in
> trouble from memory pressure, I have 4 GB of physical memory. The size
> builds quite rapidly.
>
> This is an old article published as the gc module was added to Python that
> explains a bit about gc in Python.
>
> http://arctrix.com/nas/python/gc/
>
> Because it is old it may not be 100% accurate today but does go into the
> problem some better than the reference documentation.
>
> This article was decent as well
>
> http://www.algorithm.co.il/blogs/programming/python-gotchas-1-__del__-is-not-the-opposite-of-__init__/
>
> Ron
>
>
>
>

Reply via email to