YamaKen
yamak****@bp*****
2005年 3月 10日 (木) 03:15:27 JST
At Thu, 10 Mar 2005 02:42:34 +0900, yamak****@bp***** wrote: > At Sat, 26 Feb 2005 12:50:18 +0900, > ekato****@ees***** wrote: > > これまでの uim-helper-server では、client 側が blocking write するのは > > 無理な感じです (uim-xim だと、結構な時間止ってしまうという…)。 > > uim_helper_send_message() APIは一度呼ばれたら全てのメッセージの > 書き込みが終わってから戻るインタフェイスになっているので、ここで > はblocking write以外の選択肢は取れない、もしくは意味が無いはずだ > と理解しています。 今のuim_helper_send_message()の実装(非同期write)を見て気付いたん ですが、helper-serverがmessageの送信元プロセスに書き戻す時にうま く回ってない気もします。やはりこの部分はhelper-server側でのバッ ファリングをアテにしてひたすら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モジュール > を候補に上げました。 ------------------------------- ヤマケン yamak****@bp*****
