[Python-Dev] GC Changes

[Gustavo Carneiro]

On 02/10/2007, 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.


I think close in real files is needed  not so much because you want to free
memory, but that you want to prevent data loss by flushing the file buffer
into the actual file at a certain point in time.  And I suspect that
cStringIO just added a close() method for compatibility with real files.
But of course I speculating here...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20071002/097cd4ac/attachment.htm