TOKUNAGA Hiroyuki
tkng****@xem*****
2004年 10月 5日 (火) 09:25:56 JST
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を返すので、メッセージ切れの問題はおこらないと思 うのですが、わたしは何か見落としてるでしょうか？ > ・case 2 > > 複数のメッセージが立て続けに送信された場合、今回の実装はそれら > のメッセージをひとつながりの文字列として読み出す可能性がある。 > uim_helper_get_message()内でメッセージ終端("\n\n")を検出してい > るので論理的には問題にはならないが、複数の大メッセージが連続し > た場合のバッファの消費量を抑えられず、最大消費量を見積る事もで > きない 現実的には無視できる問題だと思います。余裕があれば改善すればいいでしょ うが、とりあえずは0.4.4の方を優先したいです。 > これらを踏まえての「read_proc()内で"\n\n"を検出する」という発言 > でした。 > > > （それを後からget_messageが呼ばれるたびに細切れにして返す） > > これはちょっと意味が取れないんですが、旧実装も今回の実装も1メッ > セージ分の文字列を丸ごと返しているし、そうしないとまずいですよね? read_bufferに複数のメッセージが入っている場合、get_messageが呼ばれるた びに1メッセージずつ返すと言う意味です。 -- 徳永拓之 tkng****@xem***** http://kodou.net/
