[過去ﾛｸﾞ] ネットワークプログラミング相談室 Port4 (1001ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
230(3): 224 [sage] 02/10/31 15:13 AAS
Perlでは他の要因の方が大きいだろうけど、
Cの場合は同じように1バイトずつ読む場合でも、
fdopen()してストリームからgetc()とかで読むのと、
ファイルディスクリプタからrecv()で読むのでは
バッファの関係で速度に雲泥の差がある。
移植性の問題もあるし、fdopen()しなくても
自前でバッファリングすれば問題ないが。
>>229
保証されてるかは知らんが、毎回FILE*のバッファが
一杯になるまで満たすような実装にはしないだろ。
234(1): デフォルトの名無しさん [sage] 02/10/31 18:16 AAS
>>230
どっちが性能いいの?
243(1): 230 [sage] 02/10/31 23:57 AAS
>>234
ネタか？・・・まぁいいや。まじめに答えてあげるよ。
FILE *関係の関数、特にgetc()はマクロで実装されてる事が多いから、
バッファが空でなければ、そのチェック自身と一回の配列アクセスだけで
関数呼び出しすらなしに1バイトのデータを取得できる可能性が高い。
recv()の場合は、システムコールの最低限のコストの数百クロックに加えて、
ファイルディスクリプタや引数の値やアドレス空間のチェック、
実装によってはCPUの再スケジュールやその他もろもろが発生するから、
バッファリングされたユーザ空間だけでの場合と比べて何桁かは遅い。
>>235
ブロックして困るようならfgets()なんか使わずに自前のバッファを使うべき。
毎回FILE*のバッファを一杯にしないってのは、一回read()してバッファにデータが
残ってるうちは、満杯にするために再度read()することはないって意味だよ。
複数回read()されると、一度改行を受信してもfgets()から復帰できなくなる。
この場合、条件によってはお互いに半デッドロックって最悪な状態もありうる。
250(1): 230 [sage] 02/11/01 01:42 AAS
>>245
そう？ブロックしても困らない状況は結構あると思うよ。
勉強目的とかでクライアントをお手軽に作る場合や、鯖だとしても、
タイムアウトが必須なほど資源的に程切羽詰まってない場合とか。
でも、alerm()は有効そうだね。
EINTRで再read()する実装あったら嫌だけど(ｗ
>>246
究極的には、常にブロックを一切せずに一行読み込むのは不可能。
select()使ったとしても、タイムアウトするまではブロックするわけだし。
ただ、その待ち時間の間に他の事をできるかどうかの違いでしかない。
プログラムの関心がひとつのソケットにしかなく、
タイムアウトも無用であればブロックしようがどうでもいい。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s