bbs.cgi再開発プロジェクト 3
■ このスレッドは過去ログ倉庫に格納されています
bbs.cgiってこんな感じ? bbs.cgi ├初期処理 ├IP Address/ホスト名に依存する処理 ├書き込み内容に依存する処理 └書き込み処理 judeとかUMLツールでシーケンス図かいて、Wikiにでも置いとかね? bbs.cgiの。 クラス図とかもあるといいかも。 bbs.cgi ├IP Address/ホスト名に依存する処理 ├初期処理 ├書き込み内容に依存する処理 ├IP Address/ホスト名に依存する処理 ├書き込み内容に依存する処理 ├書き込み内容に依存する処理 ├IP Address/ホスト名に依存する処理 ├書き込み内容に依存する処理 ├書き込み内容に依存する処理 ├IP Address/ホスト名に依存する処理 ├書き込み内容に依存する処理 ├初期処理 ├書き込み内容に依存する処理 ├IP Address/ホスト名に依存する処理 ├書き込み内容に依存する処理 ├IP Address/ホスト名に依存する処理 ├書き込み内容に依存する処理 ├IP Address/ホスト名に依存する処理 └書き込み処理 簡単に書くと、こんな感じかな このスパゲティソースは、なんだか複雑な味がするなぁ。 隠し味は何かしら。 しかも>37の各処理で8番目と15番目は二つ組みでひとつの処理を・・・・(^_^;)っつー感じなんだよな >>37 さすが何十人もの手で作られた インスタントラーメンのようなものだな。 ああ、叫びたい叫びたい・・・・ ヽ( ・∀・)ノ ウンコー とかなる物ですか・・・?(汗 とりあえず、機能を買えずにに>>37 を>>35 にしてみれば? >>40 うーむ、昔ひ(りゃ がperlccしてだめだったわけだ、、、。 ひょっとしてoyster901でperlccが通ったのって、奇跡に近い? 残りの一割は ま・さ・か・・・・ いわゆる「おいらのギャグ」? >>45 同じPerl 5.6.1なのに、news8では通りませんね。 本当に奇跡かも。 cc -DAPPLLIB_EXP="/usr/local/lib/perl5/5.6.1/BSDPAN" -fno-strict-aliasing -I/usr/local/include -O -pipe -I/usr/local/lib/perl5/5.6.1/mach/CORE /usr/local/lib/p erl5/5.6.1/mach/auto/IO/IO.so /usr/local/lib/perl5/5.6.1/mach/auto/Fcntl/Fcntl.so -o ../../bbs.cgi bbs.pl.c -Wl,-E -L/usr/local/lib -L/usr/local/lib/perl5/5.6.1/mach/CORE -lperl -lm -lc -lcrypt -lutil /tmp/cc2iTuIB.o: In function `xs_init': /tmp/cc2iTuIB.o(.text+0x5927): undefined reference to `boot_DynaLoader' ERROR: In compiling code for bbs.pl.c ! gccのバージョンが違うせいかもね。 こうして、偶然と奇跡のめぐり合わせで、今日も回っているわけだ。 (2chtubo愛さん)ヾ('-'*)ナデナデ ちょっと風邪薬を配合したら、make通っちゃった。どうする? %ls -l bbs.cgi -rwxr-xr-x 1 service service 806530 Feb 15 08:41 bbs.cgi %file bbs.cgi bbs.cgi: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 4.9, dynamically linked (uses shared libs), not stripped 時間がとれたら、新oysterと旧oysterでもやってみよっかな。 今日はちょっと無理だけどね。 まぁ、奇跡があと2回ぐらい起こってもいいかなと。 まぁ、桃色方面ででも試せるかなと。 >>61 DynaLoader.a の位置を探し出して、直接くべたのですよ。 とりあえずいんちきバイナリを作る時のテクとしては、定番かと。 このへんは昔とった(りゃ。 lang/gcc32とかgcc33を4.9R鯖でもインスコするっのてはどうよ? yahoobbでスレ立てられなくなったんですか? 前スレの後半で解禁されたみたいですけどまた規制ですか? yahoo串なんですけどね すぐ規制されちゃいますよね、で規制される前に使おうと思ったら「スレッド立てすぎです」 先にこの串で立てられたっぽくないんですけどね 今、他の板で立てられましたから やっぱり先に立てられたのかなぁ >>72 >スレッド立てすぎです jp規制と関係無いじゃん。 後は。。。 携帯&●のスレ立て規制の兼ね合いですなぁ 規制の種を携帯固有番号or●固有文字列にすればいいんだが また解読の日々か・・・ ●も規制入れるんすか・・・。 断固反対!既得権益を死守するぞー!おー!! >>77 たしか●の利点は過去ログが読めるってだけだったはず。 スレ立て規制抜けやsamba抜けは漏れてただけ。 っていうか、●の規制抜けの穴埋めは一番最後でいいじゃん・・・ 何なら埋めなくても、●で荒らせば●剥奪なんだし。 過去ログが読めるだけなら、●の更新しませんわ……。 保証されてないとは言え、現状でスレッドが立てられるから、 ●購入した一人です。 つうか、運営側はサービス(機能)として認めて欲しいな。 ●買った瞬間に2chつぶれたりしませんよね? それが怖くて買えない17の夏 リスク取ったものがリターンを得るのだ。 得ないこともあるけど・・・ 1000ストッパー素突破対策はこのスレと見たがどうか。 1000ストッパーは書き込みロックファイルを作成してから1001の処理をするとかだめかな? qmail-localのパクリアイデアの続き。 /queue以下 /スレ番号 /スレ番号/cur /スレ番号/new /スレ番号/tmp ・投稿用bbs.cgiはtmpにひたすら書く。tai64time.pid.とか重複しないようなファイル名で 書き込みに失敗したらcurをみて1000から始まるファイルがないかどうかチェック。なかったらウェイトしてはじめに戻る。 ・tmpに書き込めたらnewにハードリンクしてtmpをunlinkする(投稿成功) ・dat追記デーモンはnewからひたすらcurに追記する。その際に0000から1000までの番号をファイル名の頭に追加する curに追加したファイル名でハードリンクして成功したらcurをunlinkする。 999を追記した段階でtmpをreadonlyにchmodする。1000を書く ・dat書き出しデーモンがcur以下をcatして*.datとして出力。 ・あぼーんするときはcur以下の数字を消してdat書き出しデーモンを呼び出す。 ※もし出来るならqueueをファイルシステムじゃなくてMySQlとかにするほうが性能がいいかもしれない curをcatする方法だと、スレ番号/l50とかスレ番号/1-100とかも別途書き出すのが楽。 まぁ*.datを直接読んでくれる専用ブラウザには関係ない話だけど。 IE対策にはなりそげ。 読み出す側で1001以上出力しないようにして、 レス数1000超えてたら自動的に1001のレスを付加してやったらええんでないの? 見た目1001超えなければ、書き込みも減る=妙な鯖負荷も減るだろうし。 で、状況見て書き込み側を改良していけばいいような。 >>94 それだと書き込みが「吸い込まれ」たことにならない? 「絶対に上がらないスレ」ってできませんかね? bbs.cgiで>>1 のメール欄を見て「sagesage」だったら 書き込みのメール欄の先頭に「sage」を追加する、とか。 重くなるだけで利用価値ないかな。 ていうか、そんなことを2ちゃんねるでやる必要性が感じられないな。 sageだかageだか知らないけど、2ちゃんねるはスレッドフロート式なんだから、 sage進行信仰に対する一つの答えを出すことに意味があるのですか? さあ?意味なんて考えてもみませんでした。 やったら、できたら、そうなったら面白さの幅が広がるかな、と思っただけですよ。 それがおもしろそうな機能には見えなかったんでね。 わざわざcgiを改造してまで追加する価値があるような おもしろい機能とは思えないですよ。ageらないスレなんて。 うーん、やっぱダメかなぁ。 2ちゃんねるの根幹をゆるがす面白さだと思ったんですが。 (´・ω・`)ショボーン ただ、おもしろいかどうかは個人の主観なので、 おれは全然おもしろくない機能だと思うのですが、 ひろゆきがおもしろいと思えばありだとは思うんですけどね。 あと、sageっぱなしだと他の人が入ってこないのでどうしても馴れ合いが 進んでしまう、と考えられる点もマイナスポイントかも。 ああ、馴れ合いの問題はありますね。 適用してみたいと思ったのは次のようなスレです。 ・+系板の雑談スレ ・AA系の板のスレ ・自己紹介板のスレ ・bbspinkの一部スレ ・ネタスレ ひ(ryは面白がらないっぽいなあ。 なんかそんな気がしてきますた。 実況鯖だけインビジチューニングとか?(そりゃダメだろ 1.スレッド立てる人はスレが荒れてほしくないと思い強制sage進行スレに指定 2.70%のスレが強制sage進行スレとなる 3.スレはだいたい立てた順番にならぶ 4.sageの価値そのものが低くなる こうなっちゃうんじゃない? むかしむかし、スレタイに「(10000)」と入れると上げられないスレにできたけど 「バグ」として修正されたことを考えると望み薄では 一応こちらで。 2chの動作報告はここで。 パート10 http://qb3.2ch.net/test/read.cgi/operate/1076174286/528 528 :FOX ★:04/02/25 21:44 ID:??? 問題は処理の順番というか・・・ 1) bbs.cgi の中盤で dat に追記 2) bbs.cgi の後半で subject.txt を書き換え 3) この時 dat 内のレス数カウント 4) ついでに 1,000 超え判定 → 1,001 書き込んでパーミッション変更 5) しかし既にこのときには次のbbs.cgiが目前までせまっているらしい。 1)の前に3)4)を入れられないのかと。 それだけでover 1000の書き込みははねられ、 それだけDisk I/Oの負荷が減ると思われ。 何でこんな処理になっていたんでしょ。 理由が知りたい。 >>112 最初は1000超え判定ルーチンがなかったんだよね? あとからとりあえず後ろにくっつけてみた、って感じじゃないかな。 >>112 529 :FOX ★:04/02/25 21:47 ID:??? dat のopen , close で行くと、 1) 512 超え判定、超えていたらDispError(); 2) 追記のために open -> write -> close 3) subject.txt 書き換えのために res数取得 open -> read -> close 4) 超えていたら 1,001 書き込み open -> write -> close ->chmod これなら、 open(+<);# 読み書き(追記用)両用フラグを与える write; read; if(over 1000){ white; close; chmod}; else close; endif; とすればopenの手間は一発(=1/3)ですむ。 >>114 あ、まちがいた・・・ ○| ̄|_ ×if(over 1000){ white; close; chmod}; ○if(over 1000){ write; close; chmod}; 4) のところで、 A) 999以上で書き込めるの? B) んじゃdatに1000ストッパー追記しよう C) んでもって、パーミッション切っちゃおう D) おしまい となってます。 B) に詰まっちゃって、A) をすり抜けてきちゃうのがたくさんできる予感。 >>114 まさしく dat 追記する瞬間だけど open(OUT, ">>$DATAFILE"); print OUT "$outdat\n"; close(OUT); ここで dat 数を数えて DispError() するってこと? そのあとで subject.txt を書き換えるときに また dat数数えるってこと ? >>116 あ、A) は A) 1000以上で書き込めるの? だ。 でも、実際の1000大幅超えスレでは、1000ストッパーが何回も書き込まれているのに その後から書き込みしたレスも書き込めちゃってるんだよね。 だから、Bに詰まっちゃってるのはないんじゃないかな。。 >>119 datへの書き込み後に1000越え判定するんで、有り得ないこともないですね、 512kB 超えの判定は bbs.cgi のかなり序盤 ここだとうまく行くから ここで dat数も数える? んで数を保持しておいて、、、 後半の subject.txt 書き換え部分でその数使う? すでにずれている予感もするのだが、、 ピーク時 bbs.cgi は 20回/sec くらい呼ばれているぞ それも同じ subject.txt に対して >>117 こういうことでは? open(OUT, $DATAFILE, "a+"); print OUT "$outdat\n"; @logdat = <OUT>; if (scalar @logdat > 999) { print OVER "1001<><>Over 1000 Thread<>このスレッドは1000を超えました。 <br> もう書けないので、新しいスレッドを立ててくださいです。。。 <>\n"; close(OUT); chmod(0555, $DATAFILE); } else { close(OUT); } そう、だから1000越え判定をdat追記前にもってこようと。 >>121 50ms以下ですか・・・かなりきついですね。 >>121 openのコストよりstatのほうがちいさいのであればそれてもいいかと。 そういえばbbs.cgiのcputimeってどのくらいです? それ如何によってはある程度のdat(レス)数(の意でいいのだろうか)で filelockかけるっていうことも視野に入れてもいいかなと。 まちがいなく1000近くになれば重たくなりますが、 over 1000の膨大なdisk I/Oでリソースを食うよりはましかと。 # peko級でcputimeが50ms程度でおさまっていればいいのですが・・・。 前にも書いたけど、1000レス制限は本当に必要なんだろうか……。 サイズ制限だけでも間に合うんじゃないだろうか……。 >>127 いつ書き込みできなるのか分からないし、 次スレを作るタイミングも分からないし、 とにかくユーザにとって使いづらいというかイライラすることは間違いない。 >>128 いつ書き込みできなくなるかについては、レス数のかわりにスレサイズを見るようになり、それがあたりまえになるんでは? AA系なんかだと「450K超えたからそろそろ次スレ」なんてのはあたりまえだし。 レス番号は左に確実に表示されているからどんなバカでも一目瞭然だけど。 datサイズは分からない人がたくさんいる。 はて。「サイズがxxxKBを超えています。512KBを超えると表示できなくなるよ。 」というメッセージは大きく表示されるけど。 専用ブラウザじゃ気づきにくいねぇ。 番号の変わりに番号+その時のDatサイズにしたら面白そうだけど。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる