08/11/11 07:32:00
>>878
サンクス。あきらかにNFS使ってるね。
そんなサーバがあることに驚いたけど。
881:デフォルトの名無しさん
08/11/11 07:50:04
つまりflock前提として、最適なロック方法は
「まずIO.ioctlでロックを試みる、エラーが出ればrescueしてflockする」ということか！
・・・面倒だ
やっぱり、完全に可搬性のあるファイルシステムロック用のライブラリが欲しいな
882:デフォルトの名無しさん
08/11/11 08:19:04
「完全に」とか簡単に言っちゃう人って頭悪そう。
883:デフォルトの名無しさん
08/11/11 08:36:33
不完全or不安定なライブラリがほしいって言うのもなんだと思うが
884:デフォルトの名無しさん
08/11/11 08:49:34
欲しい欲しい、して欲しい。
885:デフォルトの名無しさん
08/11/11 09:14:19
RAAやRubyForgeをざっと探してみたけど、ファイルロック用のライブラリらしきものが見当たらない
実はみんな、あまり必要としていないのか？
MLでこんな古い話は見つけたが、ソースコードはもう公開されてないっぽい
（時間ないから詳しく探してないけど）
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
886:デフォルトの名無しさん
08/11/11 09:50:16
本来、ファイルロックみたいにべったり環境依存なものに、完全な可搬性を求める発想が普通は余りないんだよね。
とはいうものの「環境依存だから諦めろ」ってのも古い考えで、こういう操作こそ処理系で環境差異を吸収しろ、っていう意見も、確かに一つの見識だと思う。
というわけで、完全な可搬性を持ったファイルロックの実装をコントリビュートしてくれ。
887:デフォルトの名無しさん
08/11/11 09:54:31
あんまり気にしたこと無かったけど、makeするあたりで
良きに計らってくれるとよさそうな感じだね
888:デフォルトの名無しさん
08/11/11 15:07:35
flockが使えるかどうかがファイルシステムに依存する以上、
コンパイル時に判定するのは無意味じゃないか?
889:デフォルトの名無しさん
08/11/11 17:32:32
>>886
SQLが使えるなら簡単な表を作って、そこに1つだけレコードを追加して、
あとはSELECT FOR UPDATEかSELECT LOCK IN SHARE MODEで終了。
幸いSQL用のライブラリは普通に配布されてる。
SQLが使えない場合はやり方を工夫するしかないわけなんだが。
とりあえずパンドラさんのPerlライブラリを解析するしかなさそうだけど。
>>881
むしろ順番は逆のほうがいい。ioctl関数はどちらかといえば汎用関数。
ioctlが使えないのはほぼ例外なくWindowsで作られてるサーバー。
890:デフォルトの名無しさん
08/11/11 17:34:51
RuBBSになんかあったな、ロック用のモジュール。
これの可搬性はどうなんだろう。
URLﾘﾝｸ(www.google.com)
891:デフォルトの名無しさん
08/11/11 17:53:13
>>890
この関数の流れは…
1.ロックファイルを固有ファイルに名前を変えようとする。成功したら3へ
2.失敗したらタイムアウトより古いロックファイルがあればロックを取得しようとする。
成功したら3へ
3.1秒待って1へ戻る。ただしtry回試して失敗したら打ち切り
4.ロックを取得できていなければLockError例外を発生させる
5.ブロックをともなって呼び出されていた場合そのブロックを実行する。
そしてロックを解放する
ロックの解除は普通に元のファイル名に変更するだけ。
汎用性はかなり高いと思われる。レースコンディションを検討しても
まずないだろうと考えられる。ファイルのリネームができないサーバーは
まずないだろうからその面でも問題はない。
892:デフォルトの名無しさん
08/11/11 18:01:12
ただし、このプログラムを使う場合、GPL2が適用されるので
それを使ったソースの配布もGPL2を用いなければならず、
そこが唯一の問題だったりする。逆に言えば、GPL2で
配布する予定のプログラムならぜんぜん問題はないといってよい。
893:デフォルトの名無しさん
08/11/11 19:05:10
>>892
自分で書き直せばいいんじゃね？
894:デフォルトの名無しさん
08/11/11 22:36:42
アトミックな処理(シンボリックリンクの作成とか)を利用したロック方法は
それなりにノウハウが枯れきっている話題だし、自分で実装しちゃえばいい。
895:デフォルトの名無しさん
08/11/12 07:21:48
試しにファイルシステムロック用のライブラリを書いてみた（不完全）
mkdir方式で共有ロック・排他ロックの区別あり
URLﾘﾝｸ(eload.run.buttobi.net)
ロック検出→ロックディレクトリ作成の間に
明らかなレースコンディションがあるんだけど、解決の方法が思いつかない・・・
何かいい解決策はないだろうか
896:デフォルトの名無しさん
08/11/12 12:34:09
すでに存在するディレクトリを指定したときにエラー返らないんだっけ？
897:デフォルトの名無しさん
08/11/12 13:20:39
Perlだけど解説は参考になるかな
URLﾘﾝｸ(www.din.or.jp)
898:デフォルトの名無しさん
08/11/12 21:36:28
>>896
Errno::EEXIST
899:デフォルトの名無しさん
08/11/13 08:41:51
改良版。レースコンディションは無くなった……と思う
その代わり1回のロックで2つのディレクトリを作るため、効率はやや悪い
URLﾘﾝｸ(eload.run.buttobi.net)
>>896
共有ロックだと、複数のロックを同時にかけられるから
「まずmkdirしてみて、失敗するならロックされている」という検出方法が使えなかった
900:デフォルトの名無しさん
08/11/13 16:44:54
ボロボロじゃん。
教科書に載るようなちゃんと知られたアルゴリズムを調べて書いた方がいいと思うよ。