---

■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50

read.cgi改良スレッド

519 ：デフォルトの名無しさん ：01/08/31 02:52 ID:BJK6ay72

ftp://210.170.170.118/incoming/bmem/bmem.c
っていうのでちょっと実験してみたんだけど(IA Solaris8)

bmem@test:~/tmp[479]% time bmem mmap
0.35u 1.78s 0:02.10 101.4%
bmem@test:~/tmp[480]% time bmem mmap.pri
0.37u 1.81s 0:02.15 101.3%
bmem@test:~/tmp[481]% time bmem mmap.pri.wri
0.52u 5.73s 0:06.21 100.6%
bmem@test:~/tmp[482]% time bmem read
0.23u 3.80s 0:03.99 101.0%
bmem@test:~/tmp[483]% time bmem fread
3.20u 4.09s 0:07.26 100.4%

確か.datをmmap()で読む時はMAP_PRIVATEにして　BigBufferに書き込み
してたよね？　これだと上記の"mmap.pri.wri"のケースに該当するんだけど
......どうしましょ？　プラットフォームによっては違う結果になる？

520 ：|　 - -) ：01/08/31 03:00 ID:W1MB8EFM

bash-2.03$ uname -sr
Linux 2.4.9
bash-2.03$ for i in mmap mmap.pri mmap.pri.wri read fread ; do echo -n $i; time
./a.out $i; echo; done
mmap
real 0m1.272s
user 0m0.230s
sys 0m1.020s

mmap.pri
real 0m1.237s
user 0m0.220s
sys 0m1.020s

mmap.pri.wri
real 0m2.454s
user 0m0.250s
sys 0m1.960s

read
real 0m6.346s
user 0m0.340s
sys 0m6.000s

fread
real 0m10.448s
user 0m1.950s
sys 0m8.490s

521 ：|　 - -) ：01/08/31 03:03 ID:W1MB8EFM

...というわけでたぶんプラットフォーム依存かと。

522 ：♯6411 ：01/08/31 03:05 ID:DT2vnGqI

>>519 検証せずにしゃべってるので突っ込み大歓迎♪

MAP_PRIVATEのときは、commitも
含むんだとおもう。なので mmap.pri の結果は順当かと。
で、そこに書き殴ったときは、カーネル内部で
・ページフォルト
・ページのコピー
がページ境界をまたぐたびに発生するんで、
オーバーヘッドはまぬがれない。
以上はｲﾊﾟｰﾝ論。

今回のケースでは、以下の前提があると思われ。
・ターゲットファイルはページキャッシュにある
　ことが多いと期待される。
・実際書き殴ってるのは、ケツの1ページだけ。
なので、read()でバッファに読み込むより
いくぶんか効率的なのでは…と思ったら、
dat_read()以外の部分でBigBuffer書き殴って
たりしないっけ? あれ? あれれ? あれれのれ?

書かないという前提があれば、readonly, sharedで
いいんだよねー。

レポートさんくすです。
ちなみにターゲットはLinux.

523 ：デフォルトの名無しさん ：01/08/31 03:07 ID:PS9zdCQg

無意味だけど一応 FreeBSD4.2

time ./bmem mmap
0.148u 2.207s 0:02.35 99.5% 10+191k 0+0io 0pf+0w
time ./bmem mmap.pri
0.257u 1.979s 0:02.23 99.5% 10+191k 0+0io 0pf+0w
time ./bmem mmap.pri.wri
0.351u 3.841s 0:04.29 97.6% 10+192k 0+0io 0pf+0w
time ./bmem read
0.357u 2.525s 0:02.90 98.9% 12+210k 0+0io 0pf+0w
time ./bmem fread
1.531u 4.327s 0:05.91 98.9% 10+215k 0+0io 0pf+0w

524 ：♯6411 ：01/08/31 03:07 ID:DT2vnGqI

>>520 早速レポートいただけるとはさすが。
参考になるす。tnx.

525 ：デフォルトの名無しさん ：01/08/31 03:11 ID:PS9zdCQg

そういえば、ターゲットのカーネルのバージョンはいくつかな。
サーバー導入時期で違ってたりして。

526 ：デフォルトの名無しさん ：01/08/31 03:17 ID:0V6W10r6

>>525
ttp://www.maido3.com/server/usagi/news.html
には Linux2.2.19 Slackware って書かれてますね

527 ：506 ：01/08/31 03:21 ID:6a8y9j3k

>>518 う　gifを生成しとるので夢の話という事ですよね。

content encoding gzip RFCひっくり返して見たが
やはりMSのヒトリヨガリの仕様のようだちなみにMSDNにも
ロクな事は乗ってなかった

糞MSのトップページみたらMSIE6が出てて鬱になった。

528 ：518 ：01/08/31 03:28 ID:PS9zdCQg

いえ、無圧縮GIFをgzip通して送出してたら、表示できないIE5があったんです。

529 ：デフォルトの名無しさん ：01/08/31 03:31 ID:pEodOMrQ

ところで、2048 バイト欠ける理由は分かったの？

530 ：506 ：01/08/31 03:36 ID:6a8y9j3k

>>529
2048欠けるのはMSIEの単純なバグ。

531 ：デフォルトの名無しさん ：01/08/31 03:39 ID:pEodOMrQ

もしそうなら IE6 でも直ってないのだけれど。やる気ないな。
どこかにこの件に関するバグレポートないのか。

532 ：デフォルトの名無しさん ：01/08/31 03:42 ID:PS9zdCQg

>>518 のような例があるので、単純なバグじゃないのかも。

533 ：506 ：01/08/31 03:54 ID:6a8y9j3k

他にも Windows2000 とかでも
accept encoding "gzip" が 「無い」　MSIEがあるようです。
OSごと入れなおすと直ったらしい　藁

>>531 MSあさりました　RFC詠んだ　mod_gzip.c読んだ 吐き気がする程に。結論は無かった
けどgzipで2048の空白なんざ数バイトになるので、あまり問題に
しないほうがいい。
なので　消防の自分は寝るよ。

534 ：デフォルトの名無しさん ：01/08/31 03:58 ID:PS9zdCQg

>>533
OS入れなおさないと直らないってところが（藁
IE再インストやverUPでなぜか直んないんだよね〜。

535 ：デフォルトの名無しさん ：01/08/31 03:59 ID:pEodOMrQ

>533
お疲れ様です…
自分も google しまくったけど手かがりなし。
原因が解明できないのは精神衛生的に良くないが、時間の無駄みたいだ。

536 ：デフォルトの名無しさん ：01/08/31 04:03 ID:PS9zdCQg

一応
http://teri.2ch.net/test/read.cgi?bbs=accuse&key=999151333&st=822&to=825&nofirst=true

537 ：音楽侍 ◆NtVkSITE ：01/08/31 04:12 ID:Ha76ETsk

いま、どこかにmake一発で動くread.cgiって保存されていますでしょうか？
公開版は一ヶ所別に置くとか、gzipになってるとか。。。

538 ：名無し娘。 ◆vP.bOZFQ ：01/08/31 04:16 ID:s8ksSf.2

>>537
http://www.gedoh.org/aki/2ch/current/bbs/
これじゃだめ？

539 ：音楽侍 ◆NtVkSITE ：01/08/31 04:24 ID:Ha76ETsk

>>538
やってみます〜

540 ：デフォルトの名無しさん ：01/08/31 04:29 ID:PS9zdCQg

Makefileに追加して、一括ファイル作りましょうよ。
http://www.gedoh.org/aki/2ch/current/bbs/
でcvs更新後に実行してくれるとうれしいな。

最低限必要なのは、下記

dist:
　tar cf - *.[ch] Makefile zlib/*.[ch] zlib/configure zlib/Makefile.in | gzip -9 > read.tgz

541 ：音楽侍 ◆NtVkSITE ：01/08/31 04:40 ID:Ha76ETsk

>>538
出来ました〜ありがとです。

>>540
ビルドごとにアーカイブして隔離していただいた方が安全です〜

542 ：デフォルトの名無しさん ：01/08/31 04:44 ID:Rl8iN43I

>>541
そのへんは cvs の tag に活躍させてもいいのでは?

543 ：音楽侍 ◆NtVkSITE ：01/08/31 04:59 ID:Ha76ETsk

>>542
私はコーディングには参加しない（動作確認とチェックだけ）ですので、CVSだと状況を追い切れません。
スレを追っての現状認識では、どれがカレントで、どれが評価版で、どれが最新か、という判断するのに時間がかかりすぎますです・・・

544 ：デフォルトの名無しさん ：01/08/31 05:09 ID:Rl8iN43I

>>543
だからこそ cvs の tag や branch を利用してみてはってことなのですが…。

545 ：♯6411 ：01/08/31 05:11 ID:DT2vnGqI

>>543
ブランチ切ってないので、
最新版 == current と捉えてくだちい。
機能評価などは、ヘッダなどでcondition outしてから
cvsのcommit logに書く、というのが一般的。

なので、何が行われたかは、cvs logで見るべし。
(どこかにcvswebのURL書いてあるでしょ?)

546 ：デフォルトの名無しさん ：01/08/31 05:11 ID:6a8y9j3k

#6411はもう寝たのかな。

547 ：デフォルトの名無しさん ：01/08/31 05:45 ID:PS9zdCQg

掲示板に戻るはindex2.cgiがあったら呼ぶようにしました。
MakefileにSRCSとdistターゲットを加えました。

548 ：aki ：01/08/31 07:14 ID:N9m3H/y.

>>547
gedoh.org のミラーで cvs up したタイミングで
make dist するように仕掛けてみました。

でもって、tag とか branch は自由にきっちゃってください。
夜勤さんや＄さんが取り込んだ版にtag切っておくといいかも。

549 ：aki ：01/08/31 07:17 ID:N9m3H/y.

でもって、レポジトリ内容はここでみれます。
http://2ch.uryusoft.net

550 ：aborn ◆OonrVZq6 ：01/08/31 07:32 ID:6m29/Im2

遅いかもしれないが…
>>533-535
インターネットオプションの詳細設定で「(プロキシ接続で)HTTP 1.1を使用する」にチェックを入れないと、
Accept-Encoding に gzip は出てきません。それのことでは。

551 ：デフォルトの名無しさん ：01/08/31 07:38 ID:PS9zdCQg

distのやり方間違ってて、毎回read.tgz作ってました。
直しました。

552 ：デフォルトの名無しさん ：01/08/31 07:57 ID:PS9zdCQg

あれ？まだ、毎回作ってる。
どおして〜？

553 ：デフォルトの名無しさん ：01/08/31 16:47 ID:vhMKUI7c

ハックですか？

＞トップ見ろよ
＞http://www.2ch.net/

554 ：デフォルトの名無しさん ：01/08/31 17:02 ID:TsVa1PVU

ネタでしょう。
本気で売るなら、ネットオークションなんかには出品しませんよ。
荒らされるの必至。つか、もう荒らされてるし(w

555 ：名無し娘。 ◆vP.bOZFQ ：01/08/31 18:10 ID:0C9lj0zQ

こんなはなしも。
http://piza2.2ch.net/test/read.cgi?bbs=tech&key=981726544&st=856

556 ：デフォルトの名無しさん ：01/08/31 19:20 ID:BJK6ay72

結局オークションはひろゆきのｼﾞｻｸｼﾞｴﾝﾃﾞｼﾀ
でもこういうことされたから　bzip2実装してやろうと思ってきた(w

557 ：デフォルトの名無しさん ：01/08/31 21:31 ID:gWobhVmY

なんかcvs重いな

558 ：♯6411 ：01/08/31 21:36 ID:WLvR5P8o

アタック受けて氏んだかと思った(ｗ

559 ：デフォルトの名無しさん ：01/08/31 22:21 ID:xu.zymnM

どこまでがネタなのかわからんな…。

そんな状況で発言するのもなんか馬鹿馬鹿しいのだが…
ページ最下部に、リロード用のリンクつくるってのはどうだろう。
st=（最新の番号-10）とかそんな感じので。
ls=100とかのままリロードしてる人間が結構いると思うので、
これって転送量結構減らせるような気がするんだけど。

って、これ、スレ違いかな？
ガイシュツだったらスマソ。

560 ：|　 - -) ：01/08/31 22:26 ID:W1MB8EFM

>>559
-DRELOADLINKですな。実装済みです。

561 ：デフォルトの名無しさん ：01/08/31 22:56 ID:KHrRCh/w

http://www.psychedance.com/test/read.cgi?bbs=tech&key=998997848
Internal Server Error
http://www.psychedance.com/test/read.cgi?bbs=tech&key=998997848&ls=10
だと大丈夫。

index関係のスレでがいしゅつかな？
http://www.psychedance.com/test/read.cgi/tech/,
で、[全レス][最新50]のリンクが全部一緒(しかもbbs=hp)

562 ：デフォルトの名無しさん ：01/08/31 22:58 ID:xu.zymnM

ごめん。

563 ：|　 - -) ：01/08/31 23:05 ID:W1MB8EFM

>>561
http://www.psychedance.com/test/read.cgi?bbs=tech&key=998997848&raw=0.0
もうまくいきません(500エラー)

564 ：♯6411 ：01/08/31 23:09 ID:WLvR5P8o

>>561 ときどきPremature end of scriptが
出るっぽいんだけど、漏れが連打した限りでは
なかなか出ない。

スレダイジェストのアンカーが不完全なのは、
まだ実装してないからです…

565 ：デフォルトの名無しさん ：01/08/31 23:23 ID:PuIIKuzw

とりあえず、
BigBufferをread-onlyにする変更をしてみた。
(>>560の分に対して)
URLリンク等もressplitter_splitに入れ、
BigLineが\nで終了(要はつながったまま)する形式になる。
全体をスキャンする回数はかなり減るはず。

またエンバグが怖いので、どなたかテスト＆mergeをお願い。
ftp://210.170.170.118/incoming/2ch-read-current/read14.2.9.c

566 ：デフォルトの名無しさん ：01/08/31 23:26 ID:PuIIKuzw

あ、全て-DCUTRESLINK時のみ有効です。
mmap()をREADONLYにはしていません。

567 ：565 ：01/08/31 23:26 ID:PuIIKuzw

名前とメールを間違えた・・

568 ：デフォルトの名無しさん ：01/08/31 23:28 ID:MkV83E8o

そういえばいつの間にかかちゅ〜しゃ規制が外れてるらしいですが、
gzip対応なわけでもないのに規制を外して大丈夫なんでしょうか?

569 ：♯6411 ：01/08/31 23:29 ID:WLvR5P8o

>>563 これだと確実に出ますねえ。
ちょっと追っかけてみるっす。

570 ：デフォルトの名無しさん ：01/08/31 23:34 ID:naodixwc

>>568
恥ずかしながら、オークションの実況をROMってしまった身から言うと、
ハマりまくってるときのリロードは1−5スレずつダウンロードすることになるね。
かちゅーしゃだとあまり関係ないと思うな。
圧縮するにこしたことはないけど。

571 ：♯6411 ：01/08/31 23:34 ID:WLvR5P8o

>>569 Content-Encoding: gzipのとき氏ぬ。
落ちちゃってるわけではなく、バッファを
フラッシュしきれてない??

gzipがない状態では、正常に処理されてる模様。

572 ：♯6411 ：01/08/31 23:39 ID:WLvR5P8o

>>571 ** デバッグ協力お願い **
サイケダンスドットコムの、
/tech/dat/998997848.datを
持ってってみてください。
たぶん、動かない予感。

bash$ (export HTTP_ACCEPT_ENCODING=gzip;
export PATH_INFO='/tech/998997848/';
export QUERY_STRING='raw=0.0';
export HTTP_USER_AGENT=console;
./read.cgi )>file

さいしょは、Linux(開発に使ってる)と
FreeBSD-2.2.x(公開に使ってる)の差かとｵﾓﾀよ…

573 ：デフォルトの名無しさん ：01/08/31 23:42 ID:WK591e.c

TODOより
>現在の実装では、/board/subject.txt のmtimeを返しているが、subject.txt
>はsage進行の時は更新されないと思われるので、上位n個スレでsage進行が行
>われているとき、正しいものが取れなくなる可能性はある。

新スクリプト(要するに今使っているbbs.cgi)では、
sageレスも必ずレス数にカウントされるので、
並べ替えは起きないものの、subject.txtの更新は行われていると思われます。

574 ：♯6411 ：01/08/31 23:44 ID:WLvR5P8o

>>573 tnx, 信じてみるよ。
ちょっと前(?)、subback.htmlとかのレス数が
sageで増えてなかったような気がして、
subject.txtも同じなのかな? と邪推
してたのであります…

575 ：|　 - -) ：01/08/31 23:49 ID:W1MB8EFM

dat_readのところの、mmapした後の盲目的strlenで問題が発生している。
本来、このコードはdatが破損してデータの一部が\0で埋められたときにそれを
できるだけ修復するためにあるコードかと思われ。
memchr(BigBuffer, '\0', zz_fileSize);を使えば問題は起きなくなるでしょう。
(その後のwhile()ループも同様に修正)

576 ：デフォルトの名無しさん ：01/09/01 00:06 ID:CHjn5Q7E

>>575
strlenは、read版だと末尾に'\0'を入れてあり、正常に動いてました。
で、>>565のコードだと、strlen使わなくなってます。

577 ：565,576 ：01/09/01 00:08 ID:CHjn5Q7E

getLineMax()の内部も変更済み。

でも、要-DCUTRESLINK。
※-DCUTRESLINKでもLINKTAGCUTが0なら、リンクのカットはしません

578 ：デフォルトの名無しさん ：01/09/01 00:25 ID:Z2Y7gl3o

ってゆーか、read()版でも、いつの間にか消えてた。

dat_read()
　・・・
　/* XXX ところどころに 0 が現れるの? */
　{
　　char *end = BigBuffer + zz_fileSize;
　　char *p = BigBuffer;
　　while ((p = memchr(p, '\0', end - p)) != NULL) {
　　　*p = '*';
　　}
　}

ブロックが汚いけど、こうすれば、OKかな

579 ：名無し娘。 ◆vP.bOZFQ ：01/09/01 00:32 ID:EhmPvxQ6

-DCUTRESLINK だとむしろ転送量が増えるかもしれない問題について、
妥協的な提案ですが、その窓内で表示されている部分だけは CUTRESKINK して、
表示されていない部分については RESLINK をはるというのはどうでしょう。
&st=50&to=100 なら、 >>58 ははらないけど >>14 ははる、というふうに。

それとも、PATH_INFO 使い出すと同時に -DCUTRESLINK はやめる方向でしょうか。

580 ：デフォルトの名無しさん ：01/09/01 00:43 ID:3xMt6oxQ

dat_read()内で、
　if (zz_fileSize > MAX_FILESIZE)
　　html_error(ERROR_TOO_HUGE);
の次に、
　if (zz_fileSize < 10)
　　html_error(ERROR_NOT_FOUND);
ぐらい、入れておいたほうがいいかもしれない。
(エラー種別は別にした方がいいかも)

実際、過去にサイズ0のファイルがあったことがある。
各フィールドの区切りや投稿日があるので
正常なdatが10バイトを下回ることは無いはず。

581 ：♯6411 ：01/09/01 00:43 ID:xtb9tuCk

ちょっと雑用が入ってしまい、
マージ作業とかできぬ、ｺﾞﾒｿ

今から帰らなきゃ…

582 ：デフォルトの名無しさん ：01/09/01 02:06 ID:lOi0M7Jo

>-DCUTRESLINK だとむしろ転送量が増えるかもしれない問題について、
読みなおしされる回数と、全体の約２割の削減(非圧縮UAのみ)で、
どちらが効果があるのか、調べないと実際にはわかりません。

で、1から「関連スレは>>2-5のどこか」とリンクされる場合は
明らかに逆効果なので、
レス１の場合はリンクするよう、とりあえず変更しました。
(>>578と>>580も加えた)
ftp://210.170.170.118/incoming/2ch-read-current/read14.2.9.c.1

書いてあるレスとリンク先のレス番号の差をみたり、
さらに、st=やls=を見て判断するのは、
単純にカットするのと比べて、閉じタグの時も判断しなければならず、
変更が大きく、
やってはみますが、それなりに重い処理になりそうです。

あと、しつこいようですけど、-DCUTRESLINKだけでカットされるわけではなく、
read2ch.h内で　　#define LINKTAGCUT 0
にすれば、カット機能は働きません。

>>581
お疲れ様です。頼りきっていてすみません。

583 ：♯6411 ：01/09/01 02:39 ID:LOycKPho

>>582 いれときました。
500 Internal Server Error問題は
解決しちゃったかな?

584 ：デフォルトの名無しさん ：01/09/01 02:39 ID:dsS601S.

rawwrite_href()をちょっと見た感じ、
st=やls=によってリンクする/しないを区別する場合には
この中でやった方がよさそうですね。
>>0や>>9999(lineMaxより大きい数字)を判断したりも、
ここで行ったほうが効率が良さそうです。

ただ、BigBufferを書き換えなくすると、
'\0'が含まれないので(逆に最後が'\n'であることが保証されている)、
　n = strcspn(*sp, ">");
　if (n == 0)
　　return 0;
は、
　n = strcspn(*sp, ">\n");
　if (*(*sp + n) == '\n')
　　return 0;
という感じになおし、
　s = strstr(s, "</a>");
　if (!s)
　　return 0;
は、
　s = strcspn(s, "<\n");
　if (*s == '\n' || strncmp(s, "</a>", 4) != 0)
　　return 0;
等の修正が要りそうです。
(他にもあるかも)

585 ：デフォルトの名無しさん ：01/09/01 02:52 ID:vzOvppvM

>>561は大丈夫っぽいけど、
>>563
http://www.psychedance.com/test/read.cgi?bbs=tech&key=998997848&raw=0.0
は直ってないっぽいです。

586 ：名無し娘。 ◆vP.bOZFQ ：01/09/01 02:53 ID:EhmPvxQ6

>>582
お疲れさまです。要はどっちにも対応できることですよね。
レス1からのリンクも明らかに逆効果かどうかわからないくらいです（＾＾；
リンク先を実際に参照してもらった回数のうち、リンクがなければ飛ぶのをやめた
人と、リンクがなくてもきちんと ls,st,to などを指定した人の分を除いた量が、
「約２割の削減」よりも大きいか小さいか。。。

ところで、そうすると -DCUTRESLINK しない場合というのは、どういう
事態が想定されているのでしょうか。
# ソース読んだだけではわからなかった（＾＾；

587 ：♯6411 ：01/09/01 02:55 ID:LOycKPho

>>585 あとでデバッガで追ってみるね(涙

588 ：♯6411 ：01/09/01 02:58 ID:LOycKPho

>>586 path仕様では、リンクの長さが
短くなるため、あえてカットせずにいます。
で、転送総量削減を期待して、
必ずchunk単位になるようにリンクを張り直します。
詳細は、サイケダンスドットコムで遊んでみてくだちい。

いまは、L-Mをchunk毎に求められるように
最適化を施してる最中です。

589 ：デフォルトの名無しさん ：01/09/01 03:18 ID:41gLtufk

rewrite_hrefなんですけど、
if (sscanf(
　"<a href=\"../test/read.cgi?bbs=%20[a-zA-Z0-9_]&key=%12[0-9]"
　"&st=%u&to=%u&nofirst=true\" target=\"_blank\">>>%u</a%c"
　, ...) == 6 && 最後の%c == '>') {
　　/* >>nn の場合 */
　　・・・
　　２つ目の'>'までカット
} else if (sscanf(
　"<a href="../test/read.cgi?bbs=%20[a-zA-Z0-9_]&key=%12[0-9]"
　"&st=%u&to=%u\" target=\"_blank\">>>%u-%u</a%c"
　, ...) == 7 && 最後の%c == '>') {
　　　/* >>nn-nn の場合 */
　　　・・・
　２つ目の'>'までカット
}
なんてのは駄目ですか？
重くなるかもしれないけど。
あ、sscanfの%[]のフォーマットに'-'を入れる場合、どうやったか忘れた。

590 ：♯6411 ：01/09/01 03:21 ID:LOycKPho

>>589 さいしょはhrefから抜こうと
思ってたんだけど、それよりも
エレメント抜き出した方が確実だと
考えたのだ。

っていうか、余所に公開するコードに
scanfを使うのは漏れの趣味じゃない。
自作一発ツールでは多用するけど(ｗ

591 ：デフォルトの名無しさん ：01/09/01 07:45 ID:UJUxMf.6

とりあえず１つデバッグ

dat_out_raw()の最後、のfor内、
　pPrintf(pStdout, "%s\n", BigLine[i]);
を
#ifndefCUTRESLINK
　pPrintf(pStdout, "%s\n", BigLine[i]);
#else
　pPrintf(pStdout, "%.*s\n", BigLine[i+1] - BigLine[i], BigLine[i]);
#endif
に直さないとまずい。(BigLineを'\n'-terminateに変更したため)

が、>>563のエラーは、BigLineの形式を変える前から起きていたので、
これが原因ではない。
>>563までの原因は>>575で、>>585の原因がこれ(↑)であれば、
解決している(かもしれない)。

あと、
http://www.psychedance.com/test/read.cgi/tech/998921988/10-20
等の時、「続きを読む」が欲しいような。
全レス表示や最新レス表示だと「新レスの表示」が出るけど。

592 ：デフォルトの名無しさん ：01/09/01 12:50 ID:twr9sQ6c

>>591
上の話 commitしときました。

593 ：デフォルトの名無しさん ：01/09/01 13:41 ID:/.JZzzqk

dat_out_index()、初めて目を通したんですが、
呼び出されるたびにdatを全部読んで解析して・・というのは
さすがに負荷が大きいような。
bbs.cgiがindex2.htmlを作成する時は、
http://piza2.2ch.net/tech/html/998997848.html
こういうファイルにキャッシュされたデータを利用しています。
これを何とか利用する方法は・・・

また、板別の設定(N_INDEX_THREADS等)は、規制実施等との整合性を保つために
http://piza2.2ch.net/tech/SETTING.TXT
の内容に合わせたほうがよいかと思います。

594 ：♯6411 ：01/09/01 13:50 ID:apo2ymi.

>>593 そのへんの仕様を知らなかったので、
あーゆー形で仮実装してたんですが、
使える設定があるのなら、喜んで
流用させてもらうです。

いずれにせよ、htmlを読んで再走査するよりは、
datから作り出した方が速い、んじゃないかなと
いうのが今の考えです。

595 ：♯6411 ：01/09/01 14:04 ID:apo2ymi.

ヘッドラインとか
広告とかの
テンプレートは
あるんだろうか?

いずれにせよこの機能は使われずじまいになる
可能性も大きいし(鬱

596 ：♯6411 ：01/09/01 14:26 ID:apo2ymi.

cvsweb 氏んでる?

あっそうだ、今日はAir H"買いに逝こう♪

597 ：♯6411 ：01/09/01 14:39 ID:apo2ymi.

>>591
> あと、
> http://www.psychedance.com/test/read.cgi/tech/998921988/10-20
> 等の時、「続きを読む」が欲しいような。
> 全レス表示や最新レス表示だと「新レスの表示」が出るけど。

「自分以降」のchunk候補を表示してあげると、
ユーザに優しくなるだろうね。漏れも思った。

…chunk表示は、ひとつだけ問題を孕んでるんだ…
それはまた後ほど話すよ…

598 ：♯6411 ：01/09/01 15:07 ID:apo2ymi.

>>563
> 500 Internal Server Error
のバグ判明。

getLineMax() の最後の方に、
BigLine[line+1] = BigBuffer + zz_fileSize;
があるんだけど、結果的にこれがsentinelの
役割を果たしてない。結果、dat_out_raw()で、
最後の行を踏むと、NULLポインタを手繰って氏ぬ。

BigLine[line] = BigBuffer + zz_fileSize;
が妥当ではないかと思うのだが、現在手元の
read.cはマージしたくないので、どなたか
追試・修正求む。

それにしても、つくづくemacs gdbは便利やのう。

599 ：♯6411 ：01/09/01 15:22 ID:apo2ymi.

>>598 これは直接関係のない潜在バグだった(鬱

最終行で、NULL - &BigBuffer[n] を計算
した結果、十分大きな値(21億超えてるかも)に
なっちゃうんだけど、BigLine[lineMax-1]は
たいていNULL terminateされているので(藁
結果オーライ、と。

600 ：デフォルトの名無しさん ：01/09/01 15:27 ID:twr9sQ6c

>>599
BigLine[line]が未記入なのは気持ち悪いのでcommitしてみた。

601 ：♯6411 ：01/09/01 15:30 ID:apo2ymi.

なんとなくわかった。
問題は、397がけっこうサイズ大きくて、
printf("%.*s") の * が耐えきれなくなってる
ものと見た。

というわけで、これをwrite/gzwriteを用いた
ものに変更すると、問題は解決
すると思うっす。

ところで、linux-2.4だと、mmap(MAP_PRIVATE)の
挙動が変わってます? 今のところ、
ファイルサイズを超えた割り当ては、
0で埋められた名無しさんメモリが割り当てられる、
という前提でコード書いてんですが…
＞ |　 - -)

602 ：デフォルトの名無しさん ：01/09/01 15:40 ID:YSt69fX.

もひとつ修正お願い。
>>591と同じところで、改行が2つ出ちゃってます。
×　pPrintf(pStdout, "%.*s\n", BigLine[i+1] - BigLine[i], BigLine[i]);
○　pPrintf(pStdout, "%.*s", BigLine[i+1] - BigLine[i], BigLine[i]);

603 ：デフォルトの名無しさん ：01/09/01 15:44 ID:YSt69fX.

>>563って、getLineMaxやdat_out_rawのprintf()の変更を加える前からです・・・
>>575が原因であればいいんだけど。

604 ：デフォルトの名無しさん ：01/09/01 15:46 ID:twr9sQ6c

>>602
あてた

605 ：デフォルトの名無しさん ：01/09/01 16:21 ID:D.BYJFUs

>>601
多分、gzprintf()が、
char buf[4096];
vsnprintf(buf,4096,format,va);か
vsprintf(buf,format,va);のどちらかになる。
下なら当然バグる。
上でバグるならライブラリの問題だが、どっちにしろ正しい結果にならない。

606 ：VC++まだ箱のなか厨房(w ：01/09/01 16:49 ID:/IvlKP0E

割り込みですいません、

動作報告にあったやつなんですが、read.cgi 5.10 で
imode経由の時、「レスを最初から読む」のリンク先が
「st=1&to=10」のためとんだページで11以降のレスを読み出すリンク
が表示されないようですが、
最新版ではこれ、「&to=11」とかなるようには対処済みでしょうか？

607 ：605 ：01/09/01 17:10 ID:D.BYJFUs

>>601
gzwrite使うようにした。

ところで、他のところで本文を一括でpPrintf()に渡しているような
ところはないかな。

608 ：605 ：01/09/01 17:36 ID:D.BYJFUs

8000文字程度のを作って食わせたら、駄目だたーョ。
zlibの方をいじった方がよさげなんだが、
スタック上に10Kぐらいとるのと、vasprintf()使うのとどっちがいい？

vasprintf()使っちゃっていいかな？

609 ：デフォルトの名無しさん ：01/09/01 17:51 ID:Oz0a82Qk

>>608 vasprintf()ってどんな関数なの？　Solaris上では見当たらないんだけど...
zlibのgzprintf()もどうせ小さな関数だから　文字列長の制限のないor制限の緩い
関数を自作しちゃってもいいかもね

610 ：605 ：01/09/01 17:55 ID:D.BYJFUs

sprintf内でmallocする。
パフォーマンス的にうれしくないが、最も安全。

printf系の関数を自作するのは、つらいっす。

611 ：デフォルトの名無しさん ：01/09/01 17:55 ID:twr9sQ6c

>>609
vasprintfってのは、第一引数をポインタのポインタで渡して
そこにメモリ確保して内容も書いてアドレス書き込んでくれる関数みたい

612 ：デフォルトの名無しさん ：01/09/01 18:12 ID:bCko6D0s

ちょっと提案なんですが、めがびーのように
「書き込み後もこのスレッドに留まる」機能を導入するというのは
いかがでしょうか？主にチャット対策ですね。
上記の機能のチェックボタンをONにして書き込みした場合、
再び最新の数十件を表示し、チェックボタンは再びONに
なっているという具合に。
脳内シミュレーションでは転送量も削減され、使用者にとっても
メリットがあり、結構いい感じなんですが・・
がいしゅつだったら申し訳ありません。

613 ：605 ：01/09/01 20:27 ID:D.BYJFUs

>>609
2ちゃんなら最大8kぐらいだから、とりあえず10kにしときました。
gzipped_fwriteは、zlibの方に移しました。

614 ：609 ：01/09/01 20:43 ID:Oz0a82Qk

>>613 とりあえずそれが妥当なところですね
vsnprintf()って確か戻り値が「バッファ長が十分あったと仮定した場合の
結果文字列長」だと思ったので　それチェックして10kより長かったら
malloc()でもっとデカいバッファ作って呼び直す　ってのもいいのかも......

でも　vsnprintf()の実装がbrokenだと戻り値が当てにならないこともあるのかな？

615 ：♯6411 ：01/09/01 20:50 ID:73Q/QYVY

現在の最新を、サイケドットコムに
反映しときました。

それにしても、Air H"さいこー。

616 ：605 ：01/09/01 20:58 ID:D.BYJFUs

>>614
たしかに、
　if the return value is greater than or equal
とかあります。

ただね、「zlibってvsnprintf()使ってんのにどうして落ちる」と悩んだんですわ。
良く見るとconfigure使うくせに STDC とか HAS_vsnprintfとかを自分で定義して
やらんといけなかった様ですな。

configureがなければ、最初っから手で調整したのにィ〜。

617 ：609 ：01/09/01 21:18 ID:Oz0a82Qk

>>616 うひゃ〜　このconfigureホントに手抜きもいいとこだな
しかし　そうなると......世の中のgzprintf()使ったプログラムには
buffer overflowの脆弱性が潜んでる可能性がかなり高い......

618 ：605 ：01/09/01 21:57 ID:D.BYJFUs

>>614 この方式も組み込みました。
10kのままにしたので、おそらくread.cgiでは使わないでしょう。

>>617 FreeBSD標準のlibzだとsnprintf()が使われるように見える。
vsnprintf()の方を使って欲しいなあ。

333KB

---

新着レスの表示

---

スレッドリストへ戻る 全部 前100 次100 最新50

0ch BBS 2004-10-30