Etsushi Kato
ekato****@ees*****
2005年 3月 18日 (金) 16:16:37 JST
加藤です。こんにちは。
On 2005/03/18, at 0:39, YamaKen wrote:
>>> このように全recipientへの送信完了を待ってから次の断片のreadに移
>>> るのではなく、コネクション毎のバッファリングとselect(2)を使った
>>> 非同期writeで解決しようというのが[Anthy-dev 1791]で意図した事で
>>> す。そして、新規にコードを書くよりは既存の実績のあるコードを流用
>>> したいという事で、要求を満たしていそうな上述のasync_ioモジュール
>>> を候補に上げました。
>>
>> 実は、試しに 0.4.6 が出る直前にそのような仕組みを今の helper-server
>> に使い、また uim_helper_send_message() を blocking IO にしたのですが
>
> これは知りませんでした。それだと話の前提が変わってきますね。
これは手元での単なる実験でして、確信しているわけではまったくありません。
また、vnc_reflector を helper-server に組み込んだわけではなく、
main loop の select で write 側の fd も把握して、EAGAIN の場合
は、queue に入れるような構造にして試してみただけです。
> その前に再確認させて欲しいんですが、現在の実装についての加藤さん
> の認識は以下のどちらでしょうか?
>
> ・コードの構造的に不自然ではあるが、通信は全ての場面で正常に行え
> るはず
>
> ・おおむね正常に動いているが、条件によっては不具合が起こり得る
現在の uim 程度の通信 (gtk/qt immodule 数個, uim-xim 一つ)
なら、正常に通信は行えるのではないでしょうか。
ただ、クライアントが多い場合で、それらのクライアントにおいて、
custom 時の prop_{list,label} のアップデートが多数のコンテキスト
で生じる場合には保障できないという感じだと思います。
> 私は加藤さんの「そうですね、必要です」という言葉が後者の状況を指
> すものだと思っていたのでコードの構造を見直す方向で話を進めていま
> した。
もちろん、write のコードの見直しが必要だと思うのですが、それだけでうまく対処
できるのかどうかよくわからない、というつもりでした。
そのため、コードの見直しも行ったうえで、ブロードキャストではなく、
toolbar と普通のクライアントを server 側で区別して write するのも手
かなと感じました。
> 私が現在問題だと思っているのはメッセージのブロードキャストという
> トランスポート層の基本機能そのものに欠陥がある(あった)事であって、
> それを利用する上層がどのようにメッセージを発行するかとは関係無く
> 解決する必要があると認識しています。
そうですね。もともと fd が同時に書き込まれる場合を前提にしてないコード
だったようですから、まず基本部分を変更しないとだめですね。
--
Etsushi Kato
ekato****@ees*****