pygtk垃圾收集运行时创建的函数是否连接到信号?

时间:2014-10-31 21:46:33

标签: python drag-and-drop garbage-collection gtk pygtk

我正在使用PyGtk。

运行时生成的功能是否会连接到信号" drag_data_get"当小部件被销毁时,小部件的垃圾收集

关于创建并与拖动源/目标目标相关联的Gtk.TargetList的相同问题?

我确实找到了Python and GTK+: How to create garbage collector friendly objects?,但它没有太多帮助。

1 个答案:

答案 0 :(得分:0)

简而言之:是的,动态创建的函数就像在运行时创建的任何其他Python对象一样创建。

更长的答案:对于垃圾收集器管理的资源,例如没有绑定到外部资源的对象,Python和PyGTK将正确处理未使用的对象。对于外部资源(例如打开文件或正在运行的线程),您需要采取措施确保正确清理它们。要准确回答您的问题,查看具体代码会很有用。通常,以下内容适用于Python和GTK:

  • Python对象(包括动态创建的函数)在无法再从Python访问之后的一段时间内被释放。在某些情况下,在对象无法访问后立即发生释放(如果对象不参与引用循环),而在其他情况下,您必须等待垃圾收集器启动。

  • 销毁窗口小部件会立即清除与窗口小部件关联的GTK资源。对象本身可以保持活着。通过窗口小部件可以访问的回调应该立即解除引用,并且如果没有其他东西从Python中保留,很快就会被释放。

您可以使用weakref模块中的弱引用类型来测试它。例如:

>>> import gtk
>>> 
>>> def report_death(obj):
...     # arrange for the death of OBJ to be announced
...     def announce(wr):
...         print 'gone'
...     import weakref
...     report_death.wr = weakref.ref(obj, announce)
... 
>>> def make_dynamic_handler():
...     def handler():
...         pass
...     # for debugging - we want to know when the handler is freed
...     report_death(handler)
...     return handler
... 
>>> w = gtk.Window()
>>> w.connect('realize', make_dynamic_handler())
10L
>>> w.destroy()
gone

现在,如果您将代码更改为handler以包含循环引用,例如通过修改它来提及自己:

def handler():
    handler      # closure with circular reference

...对destroy的调用将不再导致gone立即打印 - 这将要求程序继续工作,或明确调用gc.collect()。在大多数Python和PyGTK程序中,自动释放“只是工作”,你不需要努力帮助它。

最终,唯一可靠测试是否存在内存泄漏是在无限循环中运行可疑代码并监视进程的内存消耗 - 如果它无限制地增长,有些东西没有得到解除分配,你有内存泄漏。