Etsushi Kato
ekato****@ees*****
2005年 3月 10日 (木) 16:11:20 JST
On 2005/03/10, at 2:42, YamaKen 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単位のものでしょうか? いえ、バッファレベルの queue のつもりです。 helper-server において、コネクションごとに queue を作り、select で writable の時に、queue から送信する、という構造にするのが良いというつもりです。 たぶん、ヤマケンさんが言っていることと同じだと思います。 >> これまでの uim-helper-server では、client 側が blocking write するのは >> 無理な感じです (uim-xim だと、結構な時間止ってしまうという…)。 > > uim_helper_send_message() APIは一度呼ばれたら全てのメッセージの > 書き込みが終わってから戻るインタフェイスになっているので、ここで > はblocking write以外の選択肢は取れない、もしくは意味が無いはずだ > と理解しています。 そうです。0.4.5 では、ここで、socket を timeout 0 でチェックして、writable で無い場合は何もしていないので、かなりのメッセージが実際には伝わらないような コードになっていたはずです。 そこで、0.4.6 では、なるべく write もれが無いように、non-blocking で write(2) して、EAGAIN の場合はなるべく、retry するようになっています。 ここを、問答無用に blocking で write すると、以前書いたように、blocking IO の write(2) でかなり長い時間 (永遠) 止ってしまうことになってしまいます。 > 現在のコードを把握しきれてないので外しているかもしれませんが、こ > の「止まってしまう」という現象は以下のtimeoutベースのretryによっ > て生じているという事はないでしょうか。 そうではないようです。 >> uim-helper-server が止ってしまうような状況が稀にあったようなので、根本 >> 的な対処ではありませんが、もう少し手を入れました (uim-helper-server 側 >> も non-blocking にし、write(2) できなかった場合はある程度の timeout で >> 繰り返すことにしました)。結果的に永久的にハングすることは無くなったと >> 思いますし、write にしくじることも、手元では無いようです。 > > このように全recipientへの送信完了を待ってから次の断片のreadに移 > るのではなく、コネクション毎のバッファリングとselect(2)を使った > 非同期writeで解決しようというのが[Anthy-dev 1791]で意図した事で > す。そして、新規にコードを書くよりは既存の実績のあるコードを流用 > したいという事で、要求を満たしていそうな上述のasync_ioモジュール > を候補に上げました。 実は、試しに 0.4.6 が出る直前にそのような仕組みを今の helper-server に使い、また uim_helper_send_message() を blocking IO にしたのですが 適していないように感じました。もちろん、ヤマケンさんに書いて頂いてもう一度確認して 頂いたほうがいいと思います。 ただ、どちらかというとぼくの方は、helper server/client 側よりも、uim のメッセ ージの送信について、libuim 内でフォーカスなども把握し、また必要ないメッセージは、 ブロードキャストしない方向に持っていくほうがいいように感じています。 せっかく、uim_helper_client_focus_in とか、uim_helper_client_focus_out という API があるのに、これらが libuim の IM context で上手く利用されておらず、 bridge 側に依存してしまっているのが問題な気がします。 > 私としては餅は餅屋という方向性で、ソケットハンドリングのレイヤは > uimの開発対象から外したいと思っています。それによりどこまでが > helper-protocol固有の処理なのか線引きをハッキリさせてメンテナン > ス性を上げる事もできると思います。 いつだか、徳永さんが dbus を使おうと言っていたような記憶がありますが、その線は どうなったのでしょうか？ -- Etsushi Kato ekato****@ees*****
