Ruby/GTK应用笔记(3):垃圾回收

阅读更多
虽然垃圾回收应该属于RubyVM自动处理的事,但是一旦涉及到C扩展,情况就有些不同了。你可以在C扩展中申请资源并增加引用,导致VM无法回收资源--当然,这个属于bug,不幸的是,Ruby/GTK不是bug free

以下列出一些我碰到的这样的bug,希望后来的朋友可以借此提前看到这个坑,不要踩到里面去。

1) Gdk::Pixbuf
Gdk::Pixbuf可以用于从文件系统中装载图片资源,如果是程序中使用的图标之类的,那没问题,因为直到程序结束你才需要释放它。但是你要是反复地加载图片供Gtk::Image显示,那就要小心了,当你用Pixbuf::new(filename)方法生成pixbuf对象,此对象不被VM回收,直到GTK.main返回。测试代码:

100.times do
  pixbuf = Gdk::Pixbuf.new('my_image.jpg')
end
GC.start


观察ruby的内存占用就知道了。

Work around:
如果用Gdk::Pixbuf.new(data, colorspace, has_alpha, ...)方法生成Pixbuf对象,则此pixbuf可以被VM正确回收。这里data是图像的点阵信息,可以用其它库获得,例如可以用Camellia库,或者opencv库。


2) Gtk::Window
由于Ruby/GTK是在GTK库的API上封装ruby的API,GTK有自己的一套对象管理机制,因此Gtk::Window.new生成一个窗口对象时,内部同时注册了GTK的对象。当窗口被destroy时,并没有完全释放资源(可能某个对象的引用计数没有被正确的减一),因此ruby VM无法回收窗口对象,造成内存泄露。测试代码:

class MyWindow < Gtk::Window
  def initialize
    super
    @test = " " * (1024*1024*10)
  end
end

win = MyWindow.new
win.show_all
win.destroy
GC.start


Work Around:
手工释放资源:(
class MyWindow < Gtk::Window
  def initialize
    super
    @test = " " * (1024*1024*10)
    signal_connect("destroy") do
      @test = nil
    end
  end
end

win = MyWindow.new
win.show_all
win.destroy
GC.start

当我们手工告诉VM释放@test,VM正确地回收了@test的资源。但是实际上win对象还是没有完全释放,这个work around只是减轻了内存泄露,并不能完全避免。

以上列出的两个bug我还需要进一步dig Ruby/GTK的source,看看能不能找到根源,如果不能解决只好report到Ruby/GTK项目了。

9月7日新发布的0.17.0版本依然存在此问题,已在ruby1.8.7上测试过。

-----
[好消息,在最新的trunk代码中,r3305已经修复了此bug!在我提交bug-report仅一天之后就得到修复,看来ruby-gnome2的开发活动还是非常活跃:)]

你可能感兴趣的:(Ruby,活动,项目管理,C,C++)