Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masao M. <mu...@hi...>]

むとうです。

On Fri, 19 May 2006 19:10:25 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> From: "Kouhei Sutou" <ko...@co...>
> Date: Thu, 18 May 2006 14:37:06 +0900
> 
> > 須藤です．
> > 
> > 06/05/18 に 酒井政裕 Masahiro Sakai<sa...@to...> さんは書きました:
> > 
> > > 例えばgtk側でオブジェクトの参照関係の変更が発生する場合には、
> > > 新しい参照関係に対してG_CHILD_ADDしなおす必要がありますよね。
> > 
> > うーん，こんな場合ですかねぇ．．．
> > 
> >   xxx = widget.get_xxx # (*)
> >   xxx.signal_connect("...") {}
> >   xxx = nil
> >   GC.start
> > 
> > (*): get_xxxはなにかGTK+内部で勝手に作ったウィジェットを返す．
> 
> 実際に現在のコードで問題が起こる例を探してみました。
> 
>   fsel = Gtk::FileSelection.new
>   fsel.ok_button.signal_connect('clicked'){}
>   GC.start
>   fsel.ok_button.clicked
> 
> この場合には返り値との間に親子関係が成立することがあらかじめ分かってい
> るので、ok_button内でG_CHILD_ADDすれば良いですが、そうでない場合にはよ
> り悩ましいと思います。

手元で試しましたが、少なくともCVS版では落ちません。
理論上落ちるという話でしょうか。偶然なのかな。
なんか対応したっけ・・・・忘れてますが(苦笑)。

まぁ、でも理論的には、CHILD_ADD(CHILD_SETかな)すべし、
というのが正解だとは思うんですけど。

require 'gtk2'
Gtk.init
fsel = Gtk::FileSelection.new
fsel.ok_button.signal_connect('clicked'){p "a"}
GC.start
GC.start
GC.start
GC.start
GC.start
fsel.ok_button.clicked

> > > ですが、それはgtk側での参照関係の変更がどんなタイミングで発生するかを
> > > すべて把握していないと不可能で、新たなライブラリや将来のgtkの内部変更
> > > も考えると、それが果たして現実的な解なのか...私にはわからないです。
> > 
> > 不可能かもしれないですけど，数はそんなに多くないと思うので現実的だと思い
> > ます．あ，見付けたらそのつど直していくぐらいでいいんじゃないかという意味
> > ですけど．．．
> 
> ではもう一つ見つけた例を。
> 
>   view = Gtk::TextView.new
>   iter = view.get_iter_at_location(0,0)
>   iter.buffer.signal_connect('changed'){ puts "changed" }
>   GC.start
>   view.insert_at_cursor("foo")

こちらも、私の環境では普通に動きますね・・・。
こちらも理論的には、iter.bufferでCHILD_SETすべし、というのが正解だとは思うんですけど。

> > # あ，widget->parentがあるやつはmarkしておくというのはどうだろう．
> 
> それは良いと思います。

良いとは思うのですが、このコードを入れる場所が悩ましいですね。
Ruby/GLibにif(obj.class.gtk?)みたいなコードは入れたくないですし・・・。
 
> それと、Gtk::Container(とその派生クラス)ではmark時にgtk_container_forallで
> 子供を列挙してmarkすべきですね。そうすれば、コンテナの場合の親子関係に
> ついては個別に対処する必要はなくなると思います。

それって、例えばGtk::FileSelection.newしたタイミングで実施するイメージですかね。
確かにその方が確実かつ修正範囲が少ないとは思うのですが、それだと、性能劣化がちょっと
いやだなぁ。fsel.ok_buttonなんかで取得する際にG_CHILD_SETをこつこつ
やっていった方が、Lazyで性能的には良いと思うのですけど。

ひとまず、上記の部分はG_CHILD_SETを入れておきます。他に良いアイデアが出てきたら
そのときに削除すればいいでしょう、ということで。
＃ GOBJ2RVALP(obj, parent) みたいなマクロがあると良いのだろうか。

他にも気づいたら言ってくださいませ。

-- 
.:% Masao Mutoh<mu...@hi...>