【Perl】ファイルロック(排他処理)について語ろう
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
02/06/23 10:18ID:eY2l+Gw10609nobodyさん
03/11/21 02:13ID:???スレタイを何度も声を出してよく読んでから発言した方が良いのでは？
どう考えてもあなたのレスはどれもこのスレにはお呼びでないと思うのですが？
0610nobodyさん
03/11/21 02:23ID:???このスレには、人のことを「ヘボ」としか言わないやつがいて
それがどうもしゃくに障ったんでな。Perlの話しなくてスマソ。
0611nobodyさん
03/11/22 00:21ID:???Webアプリなら自前でログ持つ、バグ対応すること考えれば当たり前。
「ソラリス」なんて呼ぶ奴が「OSのファイルロックはアトミックじゃないっす」といった時は
使い方間違ってる確率99.9999%
0612nobodyさん
03/11/23 05:00ID:???0614nobodyさん
03/11/23 05:41ID:???単純に思いつくのはキューですが・・・
やっぱデーモンみたいな別プロセスに一括一元管理させるのが安全っちゃ安全ですよね？
0615nobodyさん
03/12/04 07:40ID:???結局、実用に耐えるファイルロックはどれなのか
スクリプト例でまとめて欲しい。おねがいｴﾛｲﾋﾄ。
0617nobodyさん
03/12/13 19:02ID:???0618nobodyさん
03/12/13 19:54ID:???0619nobodyさん
03/12/15 12:22ID:???ファイルロックなんだかDBロックなんだかわからんような
あやしげなロックが提供されるんじゃないのか
0620nobodyさん
03/12/15 19:16ID:???排他処理中はキーが書き込まれます。
0621nobodyさん
03/12/19 21:19ID:???ってこと無いですか？
0622nobodyさん
03/12/19 23:28ID:???あぁ、知識が足りなくて自分は使えないと？
やっぱりありませんね
0623nobodyさん
03/12/20 02:36ID:???if(!flock($fp, LOCK_EX)) { fclose($fp); echo "ns"; }
echo "ok";
これでいい？
0624nobodyさん
03/12/20 02:38ID:???つーかヘルプに書いてあった。
0625nobodyさん
03/12/21 05:04ID:FyNOPbG50626nobodyさん
03/12/21 16:43ID:???0627nobodyさん
04/01/08 00:54ID:???多分既出の話。
0628nobodyさん
04/01/18 18:15ID:???ブックマークから外してしまおうかな。。
0629nobodyさん
04/01/18 19:34ID:???0630nobodyさん
04/01/18 20:27ID:???いままでありがとう。
0631nobodyさん
04/01/19 01:52ID:???0632nobodyさん
04/03/11 20:28ID:???ネタが尽きたところで脱線したいんですが、
includeしたりするファイルはflockの必要が無いことを前提としているんですかね。
書き換えや追記などを行うファイルに対し、
includeやrequireしたりするのはナンセンスということで合ってますか？
0633nobodyさん
04/03/12 15:23ID:???実行するperlスクリプト本体にflockの必要があるか、という話と同じなんじゃないかと
0634nobodyさん
04/03/12 15:32ID:???0635nobodyさん
04/03/12 23:11ID:???PHPにおけるincludeやrequireは単にプログラムの記述されたファイルだけでなく、
HTML、PHP複合型やtxtまで読み込めるわけです。
そういった意味での質問です。
0637nobodyさん
04/03/15 12:04ID:???php でも perl SSI でも何でもいいんだけど、ロックが重要になるのは基本的に、
ファイルを書き換えるプロセスが複数存在して競合する場合、つまり
A:----->読み込み------->処理-------->書き出し---------------------
B:------------------->読み込み------->処理-------->書き出し-------
のようなケースね。
ロックしないとマジでファイルが壊れたり情報が失われたりする。
これに対して include や require って、
読み込みオンリーで書き換えが有り得ないという前提なので、
上記のような書き込みの競合に参加しないわけで、
そういう意味ではロックの必要性が薄い。
(全く必要性が無いわけじゃないが、ほとんどの場合無視できる)
0638nobodyさん
04/03/15 16:15ID:???厳密に言えばロックの必要性があることを示しているんですよね。
0639nobodyさん
04/03/15 16:44ID:???0640nobodyさん
04/03/15 16:44ID:???0641nobodyさん
04/03/15 18:08ID:???sh ってスクリプトを一行読み込んで実行してを繰り返すから、
実行途中にスクリプトを書き換えると結構悲惨なことになったりするよな。
0642nobodyさん
04/03/17 13:37ID:???どうもOSによっては、ファイルシステムの情報取得にタイムラグがあるようで、
renameかけても、OSが保持するファイル情報が即座に更新されないために、
同じ元ファイル名からのrenameが成功してしまうことがありました。
より正確にrename形式でファイルロックをかけるには、
rename後に若干のタイムラグを置いて、rename後のファイルの存在チェックが通れば
ロック成功と考えた方がいいですね。
ちなみに、WinXP+NTFSの組み合わせでそれらの現象がありました。
Linuxだったりすると、こういう現象は出てきますでしょうか？
0643nobodyさん
04/03/17 16:25ID:???何か間違っている。
0646nobodyさん
04/03/19 13:53ID:???仕方なく-dや-eをしなさい。
0647642
04/03/19 16:28ID:???その辺（ファイル操作後の存在チェック）は仕方なく実装してます。
同一プロセスで、同じファイルからのrenameコマンドを連続して実行すると、２回目は失敗（これが通常動作）するので、
他プロセスでのファイル操作の結果が反映されるのが遅いらしい。
0648nobodyさん
04/03/19 16:33ID:???0649nobodyさん
04/03/29 10:00ID:WLF8C9h8ログにはきちんと20万行書かれてた。
for ($i = 0; $i < 10000; $i++) {
open (DATA, ">>$file");
flock (DATA, 2);
print DATA $str;
close DATA;
}
こういうのじゃ、そのOSでflockが使用可能かって言う確認にはならないのですか？
ちなみに、環境はWin2KとActivePerl5.6.1で試しましたが。
0650nobodyさん
04/03/29 17:51ID:???そもそも flock が使用不能なら呼び出した時点で実装されてないって怒られます。
実用的に使用可能か、という意味なら実際に試してみる価値があるかもしれません。
ただし、自分の想定している条件に近くないとあまり意味がないと思います。
0651nobodyさん
04/03/31 01:14ID:???perlで壊れないロックはflock()だけだった。
0652nobodyさん
04/03/31 05:45ID:???0653nobodyさん
04/03/31 07:07ID:???どんなんだろう。
0654nobodyさん
04/03/31 12:43ID:???0656nobodyさん
04/03/31 13:50ID:???ロックに失敗してると考えると納得できる話だな > 2chがchmodでロック
0658nobodyさん
04/03/31 18:13ID:???0660nobodyさん
04/03/31 23:37ID:???どうせアトミックじゃないのなら
1000の書き込み後にchmodして
1001はクライアントで描画
dat落ち時にはdatに1001を書く、
とか適当にやれば1030くらいで止まるんじゃない？
ダサいけど。
0661nobodyさん
04/04/10 18:40ID:???運用の奴ら全員で1台のディスプレイを囲んで。
オンラインでの議論なんて無駄無駄。
0662nobodyさん
04/04/16 01:00ID:???0663nobodyさん
04/04/19 09:45ID:???ロックファイルをファイルロックしなければならなくなった。orz
0664nobodyさん
04/04/21 07:50ID:???0665nobodyさん
04/04/21 12:24ID:???よくある流行歌の「君がいるだけで」というフレーズが言い当てています。
0666nobodyさん
04/04/23 14:39ID:???0667nobodyさん
04/04/26 01:30ID:???0668nobodyさん
04/04/26 01:31ID:???0669nobodyさん
04/04/27 11:45ID:???1分でレスしてきた君のためにGTO神書き換えのレスで返そうかと思ったけど、難しいのでやめた。
例えば、/path/to/dataというパスのファイルをファイルロック中は/path/to/data.lockとするぷろぐらみゅがあるとして、
その横で
while(1) {
open(F, '>/path/to/data');
close(F);
open(F, '>/path/to/data.lock');
close(F);
}
なんてことされたらたまんねぇと。
まあ、適切にパーミッションを設定すれば問題ないのだが、
私はファイルは0666、ディレクトリは0777でも問題ないことを信条としてるのであれかなと。
0670nobodyさん
04/04/27 13:29ID:???それは、前提が間違ってると思う。
「みなさん、ロックのためのリソースの○○はこうこうこういうふうに使いましょう」
っていう規約をみんながきちんと守ってる、っていう前提で設計しないと。
そんなこと言ったら、「ハカーが○○してきたら」とか「電源落されたら」とか
「スーパーユーザに○○されたら」とか考え出したら何もできないと思う。
0671nobodyさん
04/04/27 13:54ID:???ﾊｧ?お前は Ｋ Ｅ Ｎ Ｔ か？
アップローダーを例に取るとサーバーとユーザーの設定次第で
http://pc5.2ch.net/test/read.cgi/hp/1076940865/888n
のような事も起こってしまうわけで。
専用のサーバーを使うなら>>670のような設計で構わないと思うけど、
こっちは共用向け、大量配布だからな。そういうわけにはいかんのよ。
0672nobodyさん
04/04/27 14:22ID:???「 Ｋ Ｅ Ｎ Ｔ 」というのは何だか知らないけど、そういうことなら納得です。
＃ でも >>667 のようなレスからそんな事情は推し測れないよ。
0673nobodyさん
04/04/27 17:59ID:???初回起動時にランダムな文字列のディレクトリ名やファイル名をスクリプトが自分自身の中に保存して、
それを使い rename()(または mkdir() や open() で作成)してそれをベースとするとか。
ディレクトリ内の一覧表示とかに弱いし総当りもあるし完璧では無いけど。
0674nobodyさん
04/04/27 18:00ID:???なんてこったい。
0675nobodyさん
04/04/27 20:43ID:???0676nobodyさん
04/04/28 01:00ID:???0678nobodyさん
04/04/28 01:51ID:???0679nobodyさん
04/04/28 02:52ID:???話を始めるようにしようよ。
でないと議論にならないし不毛すぎるよ。
>>667 みたいな話の切り出し方は最低。
0680nobodyさん
04/04/28 16:51ID:???0681nobodyさん
04/04/28 17:14ID:???0682nobodyさん
04/04/30 17:27ID:???そんな物を使うぐらいならソケットでプロセス間通信をしてしまう方が楽であると思うが、
Perlなんかでそんな事したらパフォーマンスが(以下略
0683nobodyさん
04/05/19 04:13ID:???誰かがファイルオープンしているときに別プロセスからファイルを読みこもうとした場合openエラーになっちゃいますよね。
それが嫌な場合は
open(DATA,"< test.txt");
flock(DATA,1);
なんたらかんたら
close(DATA);
みたいにして一人がオープンしている間は別プロセスには待たせればよろしいんでしょうか？
flockの説明を見てみると読みこみだけの時用の番号がなかったので、不安です。自分のＰＣはwin98なのでflockは使えませんし、
鯖にぶつけ本番はいやだなと思って聞きにきました。
0685nobodyさん
04/05/19 07:03ID:???書き込みの処理が２つ以上同時に行われないと分かっている場合
かつ、一過性の読み込み失敗を許容する場合
書き込みにロックは不要ですか？
0686nobodyさん
04/05/19 09:38ID:4B5lUTgr話はそれからだ
0688683
04/05/19 17:00ID:???いらないんですか。ということはアクセス集中によるオープンエラーは読みこみだけならば
起こらないということですか？
本当は自分でその状況を作り出してテストしてみたいんですけど、動作テストはwin98に入れたhttpdなので
同時アクセスが試せないんですよね。
ファイルオープンするCGIがユーザに色んな項目を記入してもらった次のページなのでエラーが
でちゃうとまた、入力してもらう事になってしまうのでそれはまずいなと思いまして；
0689nobodyさん
04/05/19 18:15ID:???これがそもそも勘違いだしな。
0690nobodyさん
04/05/19 19:43ID:???Windows はどうだか知らんけど、
UNIX なら読み出すだけならアクセス集中でオープンエラーなんてないだろ。
つーか、そこまで信頼性高いシステムが必要なら、２ちゃんなんかで質問するより、
もっとちゃんと調べて勉強するか、外注に出した方が良いんじゃないか？
0691683
04/05/19 23:00ID:???ありがとうございます。
吐いた制御ってオープンエラーを防ぐんじゃなくて、書きこみが同時に行われてファイルが壊れるのを
防ぐためにあるってことですね。
>>690
ありがとうございました。
0692685
04/05/20 15:35ID:???返答ありがとうございます。
>>686
Dirty readとは書き込み中に読み込めるということで、最新でないものを読み込めてしまうということでしょうか。
それは構いませんし、リロードで直る一時的なものであれば読み取りが0バイトでも構いません。
>>687
そういう事になるかも知れません。
言い換えると
書き込み処理が重複しない時、理論的にファイルが壊れるか否かが知りたいのです。
0693nobodyさん
04/05/20 20:28ID:???その中でも「書き込み処理が重複する」という原因はよく起こる。
この重複を避けるための道具が、ファイルロック。
ロックは、これさえかければファイルが壊れなくなるという魔法の杖ではない。
ロックは単なるプログラミングの道具に過ぎず、
それも、ファイルを壊さなくするための道具ではなく、
書き込みが重複しているかどうかを識別するだけの道具。
識別した上で書き込みが重複しないようにプログラムを書くのは、プログラマの責任。
逆に、書き込みが重複しないということが100%保証されているなら、
ロックをかけてもかけなくても変わらない。
もちろんその場合でも、書き込み処理重複以外の原因でファイルが壊れることは、いくらでも考えられる。
0694nobodyさん
04/05/20 20:38ID:???保証する方法なんてあるのか？
0695nobodyさん
04/05/20 21:07ID:???まではいい事言ってると思うんだが最後の方になって壊れてるな。
0696nobodyさん
04/05/20 22:40ID:???単に、書き込みが100%重複しない論理空間を仮定すれば、というだけの話でしょ。
もちろん現実にそんなことはありえないと暗示しているわけで。
0697685
04/05/21 01:02ID:???>>693
という事は書き込みが重複しないなら、
ファイルロックで防げる程度のトラブルは防げるという事ですね。
>>694
書き込み処理を行えるのがパスワードを知っている1人なのです。
パスワードが他人に漏れず、その1人が同時に操作せず、
openしたまま処理が中断することもない・・・
という仮定はありますが。
ファルイロックの基本的な知識さえない私に丁寧な回答ありがとうございました。
0698nobodyさん
04/05/27 13:48ID:???けっこうｳｿ書いてあるサイトが多いのに驚いた。
0700nobodyさん
04/05/27 20:14ID:???0701nobodyさん
04/05/27 21:10ID:???0702nobodyさん
04/05/27 21:08ID:???0703nobodyさん
04/05/28 01:38ID:???見せてよ
0704６９８
04/05/28 11:16ID:???自分で掴み取れ！ これに尽きるな
0705nobodyさん
04/05/28 15:29ID:???0706nobodyさん
04/05/30 14:43ID:???0708nobodyさん
04/05/30 18:12ID:???0709nobodyさん
04/05/30 22:14ID:???を使う。速いしいいぞ。
■ このスレッドは過去ログ倉庫に格納されています