YamaKen
yamak****@bp*****
2005年 3月 10日 (木) 02:42:34 JST
ヤマケンです。加藤さん、こんばんは。 At Sat, 26 Feb 2005 12:50:18 +0900, ekato****@ees***** wrote: > On Wed, Feb 09, 2005 at 05:02:57AM +0900, > YamaKen <yamak****@bp*****> wrote: > > > 加藤さんのおっしゃる通り、根本的なコードの見直しはまだ必要ですね。 > > これは0.4.6リリース後に行う事になるでしょうか。 > > そうですね、必要です。 0.4.6リリースに必要な作業の数々ありがとうございました。私も安定 版の開発に時間を割けるようになったので0.4.7に向けて検討を進めま しょう。 > > VNC Reflectorのasync_ioというモジュールがこれらの機能を一通り提 > > 供しているようなので、0.4.6リリース後にこれを使って > > uim-helper-serverを再実装するといいんじゃないかと思います。もっ > > と適したコードをご存知の方はお教えください。 > > > > http://sourceforge.net/projects/vnc-reflector/ > > uim-custom すると、結果的にかなり callback が動くようなので、 > uim-helper-server 側に queue でも作らないといけないような気がします。 私は[Anthy-dev 1791]で言った通りバイトストリームレベルのバッファ リングで大丈夫だと思っているんですが、ここで言うqueueとは helper-protocolレベルのmessage単位のものでしょうか? > これまでの uim-helper-server では、client 側が blocking write するのは > 無理な感じです (uim-xim だと、結構な時間止ってしまうという…)。 uim_helper_send_message() APIは一度呼ばれたら全てのメッセージの 書き込みが終わってから戻るインタフェイスになっているので、ここで はblocking write以外の選択肢は取れない、もしくは意味が無いはずだ と理解しています。 現在のコードを把握しきれてないので外しているかもしれませんが、こ の「止まってしまう」という現象は以下のtimeoutベースのretryによっ て生じているという事はないでしょうか。 > uim-helper-server が止ってしまうような状況が稀にあったようなので、根本 > 的な対処ではありませんが、もう少し手を入れました (uim-helper-server 側 > も non-blocking にし、write(2) できなかった場合はある程度の timeout で > 繰り返すことにしました)。結果的に永久的にハングすることは無くなったと > 思いますし、write にしくじることも、手元では無いようです。 このように全recipientへの送信完了を待ってから次の断片のreadに移 るのではなく、コネクション毎のバッファリングとselect(2)を使った 非同期writeで解決しようというのが[Anthy-dev 1791]で意図した事で す。そして、新規にコードを書くよりは既存の実績のあるコードを流用 したいという事で、要求を満たしていそうな上述のasync_ioモジュール を候補に上げました。 私としては餅は餅屋という方向性で、ソケットハンドリングのレイヤは uimの開発対象から外したいと思っています。それによりどこまでが helper-protocol固有の処理なのか線引きをハッキリさせてメンテナン ス性を上げる事もできると思います。 ------------------------------- ヤマケン yamak****@bp*****
