Qua, 2005-12-28 às 12:39 +0100, Matthias Bläsing escreveu:
> Hey,
>
> I'am new to pygtk and I'am wondering how subclassing is supposed to
> work. I did some classes, which derive from gtk.VBox,
> gobject.GObject, ... So far so good.
>
> But I have a class, from which several Instanzes (in the extreme > 1000)
> are created, which should be destroyed shortly afterwards. From looking
> at top, I noticed, that the memory consumptions grows over time and here
> the strange thing started.
>
>
> I stripped my Class to it's skeleton and tested - and when calling the
> pygtk Konstruktor, it prevents the objects from getting destroyed, after
> the last reference goes out of scope.
>
> With the attached class I get:
>
> [EMAIL PROTECTED]:~/src/player-python$ python
> Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
> [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from test2 import Musikfile
> >>> musik=Musikfile("u")
> >>> musik=None
> Musikfile destroyed
> >>>
>
> But without any surprise I can't call any gtk functions on it:
> >>> musik.connect("error", test)
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> TypeError: object at 0xb7cf98ec of type Musikfile is not initialized
> >>>
>
> But when I comment in the superclass Konstruktor, the object isn't
> destroyed:
>
> [EMAIL PROTECTED]:~/src/player-python$ python
> Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
> [GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from test2 import Musikfile
> >>> musik=Musikfile("u")
> >>> musik=None
> >>>
>
> You see, the Destructor isn't called! (It's the same when I subclass
> from gobject.GObject, which I indeed did first)
>
> Is there something wrong in my thoughts, am I overlooking something or
> is there a bug hidden between these few lines?This is a complex issue. Currently, PyGTK objects include a symbiotic relationship between a GObject and its python wrapper (PyGObject); the python wrapper refs the GObject, and the GObject refs back the python wrapper. The only way they are freed is with the help of the python cyclic garbage collector. That happens automatically after a certain number of objects are allocated, or can be forced with gc.collect(). We're trying to improve this situation; see bug #320428. If you apply that patch, deallocation is immediate for most cases. Without that patch, your object is not automatically freed because the python cyclic GC refuses to free objects that are part of a cycle and have __del__. See http://www.python.org/doc/current/lib/module-gc.html """ garbage A list of objects which the collector found to be unreachable but could not be freed (uncollectable objects). By default, this list contains only objects with __del__() methods.3.1Objects that have __del__() methods and are part of a reference cycle cause the entire reference cycle to be uncollectable, including objects not necessarily in the cycle but reachable only from it. Python doesn't collect such cycles automatically because, in general, it isn't possible for Python to guess a safe order in which to run the __del__() methods. If you know a safe order, you can force the issue by examining the garbage list, and explicitly breaking cycles due to your objects within the list. Note that these objects are kept alive even so by virtue of being in the garbage list, so they should be removed from garbage too. For example, after breaking cycles, do del gc.garbage[:] to empty the list. It's generally better to avoid the issue by not creating cycles containing objects with __del__() methods, and garbage can be examined in that case to verify that no such cycles are being created. """ Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic.
signature.asc
Description: Esta é uma parte de mensagem assinada digitalmente
_______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
