[Python-Dev] GC Changes

[Gregory P. Smith]

On 10/2/07, Hrvoje Nikšić <hrvoje.niksic at avl.com> wrote:
>
> On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> > Correct.  And that reminds me of the limitation of the the Python GC:
> > it doesn't take into account how much memory is being indirectly
> > retained by a Python Object.  Like in the example I already gave,
> > gtk.gdk.Pixbuf can easily hold hundreds of megabytes, yet the GC gives
> > it as much consideration as it does to a simple python integer object
> > which is several orders of magnitude smaller.
>
> That sounds like a case for the Pixbuf object to have a "close" method
> (not necessarily called that) that releases the resources.  The point of
> GC is that you normally don't care if memory is released sooner or
> later; for stuff you do care about, such as files, shared memory, or
> even large memory objects, there is always explicit management.
> cStringIO's "close" method provides a precedent.


Agreed, objects that consume a lot of resources of any type should have a
method to clean themselves up or the language should take special notice of
'del myObject' and call the destructor immediately if nothing else refers to
the object at that point rather than leaving it up to a GC.  Its just good
programming practice to do such things on "large" objects regardless of the
underlying allocation implementation.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20071002/4e55dcd5/attachment.htm