自作CGIを評価するスレ (672レス)
前次1-
抽出解除 レス栞

リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
371
(16): 03/06/24 13:54 ID:01cZwzPj(1/5) AAS
>>368
このルーチンだと穴がある。経験則だけど、アクセスが殺到すると簡単に壊れる。
説明するのめんどいので、

外部リンク[htm]:www.din.or.jp

この辺りでも読んでみて。

>>370
好みだと思う。

個人的には>>368>>369>>370もループの最中にreturnやら&errorで関数の
外に飛んでるので気持ち悪い(これも好みの問題)。
省8
372: 368 03/06/24 14:57 ID:??? AAS
>>371
ありがとうございます。
ロックが甘いということは分かりましたが、アンロックはどうでしょうか?
まだ371さんがおっしゃったサイトは見てないのでなんとも言えませんが…。

もう少し勉強してみることにします。

指摘されたリトライですが、
if (--$retry <= 0) {
こうですね。
373: 03/06/24 15:24 ID:??? AAS
>>371
> このルーチンだと穴がある。経験則だけど、アクセスが殺到すると簡単に壊れる。
> 説明するのめんどいので、

> 外部リンク[htm]:www.din.or.jp

> この辺りでも読んでみて。

その辺り読んで、載ってるルーチンそのまま使ってテストした所、
ファイル壊れました。

俺は、>>368くらいの簡単なロックで良いと思うけど。
このロックで壊れるようなアクセス受けてるって事は、
その説明に載ってるようなルーチンでも、ほぼ壊れる。
省3
381: 371 03/06/24 15:46 ID:01cZwzPj(2/5) AAS
> どんなロックしててもファイルは壊れるんだから、

そんなことはない。

というか、上(大崎氏の)のルーチンでファイル壊れたんならファイルシステムに
不備があるか、打ち間違いがあるかパーミッションやらの設定を誤ってるかどれか。
ファイルシステム上でrenameが衝突しないという条件の元でならうまく行くはず。

アクセス集中でファイルが壊れるのはロックの機構に不備がある
だけで、正しい状況下で行われたUNIX系OSでのflockでは、ファイルシステム
にバグがあるか、ファイルシステム自体のクラッシュでもない限り壊れない。

>>375
flockはNFS越しの場合に失敗するから、ファイスシステムを予め
省8
382: 371 03/06/24 15:48 ID:01cZwzPj(3/5) AAS
>>377
ネットワークファイルシステムを使ってる場合はね。
それ以外で壊れるという話は(ファイルシステム開発中のバグ以外は)
聞いたことない。再現できたら結構すごいと思うが。
383: 371 03/06/24 15:54 ID:01cZwzPj(4/5) AAS
変な憶測並べる前にFAQくらいみんな読もうよ。

外部リンク[html]:elib.cs.berkeley.edu
385
(1): 371 03/06/24 19:10 ID:01cZwzPj(5/5) AAS
>>384
2つのプロセスが同時に追加書込しようとしたら、
その部分は壊れるよ。
386
(1): 03/06/24 20:17 ID:??? AAS
>>371
って言うかOSが関与しないファイルロックで信頼できるアルゴリズムってあるの?
390
(1): 371 03/06/24 20:45 ID:??? AAS
>>386
symlinkにしろ、rewriteにしろ、mkdirにしろ、OSがファイルシステム上で衝突しないように
設計されているという大前提で作られてるし、実際衝突するかどうかはOS次第なので、
OSに非依存で汎用可能なアルゴリズムっていうのは原理的に不可能じゃないかと。
394
(2): 03/06/25 00:00 ID:??? AAS
AA省
399: 371 03/06/25 00:59 ID:Q5i43+wA(1/3) AAS
>>396
> 全体に一度だけかけろとか言うのか?

だってそうしないとカウントが飛んじゃうでしょ。

> 試して、壊れなかったら文句言いにこいや。

一度に5プロセス動かして1000までやってみたけど壊れないね。
FreeBSD2.2.2 + Perl5.6.0だけど。

OS何使ってて壊れるの? > 396
400: 371 03/06/25 01:03 ID:Q5i43+wA(2/3) AAS
プロセスを7つに増やしてテスト中。
時々ロックファイルが消えるな・・・。renameしかしてないはずなので、
ファイルシステムのバグか?

でもデータが壊れるということは今のところない模様。テスト続行中。
401: 371 03/06/25 01:13 ID:Q5i43+wA(3/3) AAS
FreeBSD2.2.8 + Perl 5.6.0でも実験したところ、20000件超えてるけど、特に問題なし。
FreeBSD2.2.2の方も、10000件行ってエラーなし。
合計30000件実験してみたけど衝突は起こってない模様(プロセスの譲り合いで片方のプロセスが
ブロックする現象は見られたが)。

単にrenameシステムコールが衝突するようなファイルシステムを持つOSを使ってるだけ
とか、そういうオチじゃなくて?>>398
402
(1): 371 03/06/25 01:22 ID:??? AAS
ファイルが消える現象は、ロックファイルをディレクトリにすることで回避
# mkdir lockdir/lockfile

で、20プロセス同時起動で、30000件やってみたけど、全く問題なし。
さすがに30000回連続で20プロセスが同時に1つのファイルにアクセス
する状況はありえないだろうから、少なくともウチの環境上では
きちんとロック機構が機能してると思われる。

で、たった2プロセス同時起動で10000件持たないファイルシステムを
持つ環境がどんな環境なのかとても気になるので早く教えてください>>398
あなたの言う条件↓は満たしましたよ。

> 文句言う前に試せやハゲ。
省1
404
(1): 371 03/06/25 01:49 ID:??? AAS
> こっちの環境は、Win2kだけど。

多分そのせいじゃないかなぁ。ファイルシステム何になってます?
こっちは今のところ30プロセス同時起動で30万件ノンストップで突破してるので、
スクリプト自体に問題があるとは思えない。
まぁ、このルーチンはrenameの堅牢性に頼ってるので、その点において汎用性は
薄いということを証明する形にはなったかも。

> 2kで、そんなバグ聞いた事ない。

1秒間に同じファイルを数十回renameする必要性ってあまりないからなぁ。
renameのファイルの取り合いって普通の状況だとまず起こりえないし。
ソース読んだら分かると思うけど、renameの空振り以外に原因は考えにくい
省1
406
(1): 371 03/06/25 02:28 ID:??? AAS
>>405
>>394のソース直した?部分的でなく、全体をロックで囲まないと誤動作するよ。
print文の直上直下にあるunlockとlockの2行を外せばうまく行くと思う。
408: 371 03/06/25 11:01 ID:??? AAS
>>407
> 結果は、壊れないファイルロックが存在したって事か?

昨日、あのまま30プロセス同時起動のまま寝て、今朝見たら400万件を
突破してました。もちろんノンストップで。

30プロセスが400万回連続で殺到しても平気だということなんで、
少なくともウチの環境では、ほぼ「絶対に壊れないロック機構」と言い切って
差し支えないと思う。

どうでもいいけど、このテストスクリプトだと、count.txtを書き込みオープンした
瞬間にプロセスが落ちるとカウンタリセットされるよね。堅牢なスクリプトを作ろうと
思ったらそこまで気を遣う必要があるかも。
省4
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.024s