福嶋です。

Masaki Fukushima <fukusima / goto.info.waseda.ac.jp> wrote:
> これだと、いったん Ruby 側のスケジューリングに入ってしまうと、し
> ばらくは gtk 側に制御が戻りません。まあ GUI ですし、100ms くらい
> なら実質問題は無いはずですが。
> 
> そもそも根本の問題はruby側とgtk側の両方で同時にI/O待ちが起こる可
> 能性があることだと思います。

要は

 1. Ruby側でのI/O処理の遅延を避ける
 2. Gtk 側でのI/O処理の遅延を避ける  (I/Oの遅延 == イベント処理の遅延)
 3. CPUの無駄なbusyを避ける

の3つを同時に満たすことができるかということ問題でしょうか。

現状のruby-gtkでは2と3が優先されていたので、socketで問題が起こり
ました。

私のパッチはこれを1と3を優先するようにするものです。その代わりGtk
側での I/O 処理 (==イベント処理) が遅れます。

> 一つの select にまとめられれば解決す
> るんじゃないかと思いますが、それは現状では無理っぽいですね。

と書きましたが、g_main_set_poll_func() というglibの関数を使えば
gtk側でI/Oのポーリングに使われる関数を差し替えられるようです。こ
れを使ってruby側で待っているfdとまとめてselect()するような関数を
書けば全て解決できるのかも。

---
福嶋正機