YamaKen
yamak****@bp*****
2004年 10月 5日 (火) 10:30:29 JST
At Tue, 5 Oct 2004 09:25:56 +0900, tkng****@xem***** wrote: > > On Tue, 05 Oct 2004 08:02:14 +0900 > YamaKen <yamak****@bp*****> wrote: > > > ・case 1 > > > > OSの実装や動作状態によってはメッセージの一部だけread(2)可能状 > > 態になるのが遅れる事があり得る。その場合はselect(2)でready状態 > > のfdが無かったからといってメッセージの終端まで読み終えたわけで > > はなく、旧実装と同様にメッセージ切れの問題を起こす > > get_messageは読み込んだバッファの先頭から＼n\nを探して、＼n\nがなければ > バッファはいじらずにNULLを返すので、メッセージ切れの問題はおこらないと思 > うのですが、わたしは何か見落としてるでしょうか？ 私の理解不足でした。すいません。 uim_helper_read_proc()の仕様変更がuim_helper_get_message()の意味 を変えた(1回のuim_helper_get_message()でメッセージ読み出しが完結 するとは限らない)事に考えが至りませんでした。 uim_helper_get_message() が一旦メッセージの読み出しに入ったなら ばエラーが発生しない限りメッセージ全体を読み出して返すものだとい う先入観で考えてしまっていました。 今回の件に限らず、最近自分のモノサシでのみ物事を測って他者の意図 を十分理解できていない、また自分の意図を十分に伝えられていないと いうケースが増えたように思います。今さらながら恥ずかしさに気付い たので、今後はもう少し注意深く考えようと思います。今後私にそういっ た傾向が見られたら遠慮なくご指摘ください。 ただ、自分の理想を引っ込めるという意味ではないので、今後も口やか ましくあれこれ主張する事自体は変わらないと思います。ご了承くださ い。 > > ・case 2 > > > > 複数のメッセージが立て続けに送信された場合、今回の実装はそれら > > のメッセージをひとつながりの文字列として読み出す可能性がある。 > > uim_helper_get_message()内でメッセージ終端("\n\n")を検出してい > > るので論理的には問題にはならないが、複数の大メッセージが連続し > > た場合のバッファの消費量を抑えられず、最大消費量を見積る事もで > > きない > > 現実的には無視できる問題だと思います。余裕があれば改善すればいいでしょ > うが、とりあえずは0.4.4の方を優先したいです。 了解です。 > > > （それを後からget_messageが呼ばれるたびに細切れにして返す） > > > > これはちょっと意味が取れないんですが、旧実装も今回の実装も1メッ > > セージ分の文字列を丸ごと返しているし、そうしないとまずいですよね? > > read_bufferに複数のメッセージが入っている場合、get_messageが呼ばれるた > びに1メッセージずつ返すと言う意味です。 そういう意味でしたか。理解しました。 ------------------------------- ヤマケン yamak****@bp*****
