あき
attin****@kk*****
2006年 2月 10日 (金) 18:22:37 JST
あきです。 > 竹添です。 > > 06/02/10 に あき<attin****@kk*****> さんは書きました: > > > やはりダウンロードカウンタでは正確な値が知りたいと思うのと、すでに値が > > > 消えるという状況が頻発している状況で更新のみにロックをかけても、ファイル > > > が壊れることはないかもしれませんが、かなりの確率で古いデータで上書き > > > されてしまうことが目に見えてますよね。 > > > > う〜ん。「かなりの確率で…」というのは問題を過大に見積られている気がしま > > す。 > > 現状のシステムでカウンタが頻繁にクリアされてしまうのは、全添付ファイルの > > カウンタが一つのファイルで管理されているからですよね。（添付ファイル毎に > > カウンタ管理用のファイルも分けられていれば、衝突が発生する確率は格段に低 > > く抑えらているはず） > > かつ、衝突が発生した場合に、全情報がクリアされてしまうところが問題を大き > > くしてしまっている原因です。 > > 書き込み中ファイルの読み込みを回避できれば、たとえ衝突が起きたとしても > > 影響があるのはその対象の添付ファイルのカウンタのみです。かつ、カウンタが > > ０になるのではなく、カウントアップしないだけですので、大した問題ではない > > と思います。 > > （現状だと、２人のユーザが、それぞれ異なる添付ファイルを同時にダウンロー > > ドしただけで、全ダウンロードカウンタが０にクリアされてしまいますが、別名 > > 保存→リネームにした場合は、同時にダウンロードされようとした一方の添付 > > ファイルのダウンロードカウンタだけがインクリメントされないだけとなります） > > 決して確率は高くないと思います。 > > インクリメントされないか、全ての値がクリアされるかという現象の違いは > ありますが、現象が発生する確率は同じじゃないですか？ そうですね。確率的には同じです。 違いは被害の大きさでした。 > 確かに問題の重大さという点では全然違ってきますが、後述するように対応 > すること自体はそんなに難しいことではないですし、プラグイン開発者にしても > 別に嫌なら使わなければいいわけで、同期更新用の関数があってもそんなに > 害はないでしょう。 影響範囲が広くなければ構いません。 読み込みのみか、読み書きかでロジックを切り分けるのは「影響範囲が大きいか な？」と思ったもので…。 > > > ただ、Util.pmの設定ファイル読み書き用APIは、あくまで設定ファイルの読み > > > 書きを行うもので、もともとダウンロードカウンタのように頻繁に更新が発生 > > > するケースでの使用は想定していませんでした。ですので読み書きロックに > > > 関してはUtil.pmではなく、ダウンロードカウンタのプラグイン内部で自前で > > > 行うといった整理はありえると思います。 > > > > はい、状況が異なりますので、別でもよいと思います。 > > ただ、同様のプラグインを自前で作成する方のためにも、排他制御に関する部分 > > だけはAPI化しておいた方が良いと思います。 > > まぁ、他のプラグインからも使えるようにするならやはりUtil.pmですかね。 そうですね。 > > > > もちろん、簡単に対応できるならそうすべきですが、ちょっと考えただけでも > > > > 肥大化してしまいそうですよね？ > > > > コーディングコストと成果のバランスは是非とも大切にして頂きたく…。 > > > > > > 肥大化というのはちょっとわからないです。どういうことでしょうか。 > > > > すみません。分かりにくかったですね。 > > これは私の個人的な拘りでもあるのですが、私は、ソースのボリュームと機能の > > ボリューム（完成度を含む）のバランスをとても大切に考えています。 > > 簡単に言いますと、最小限のステップ数で最大限の効果を提供したい、と…。 > > そこに技術者としての誇りを感じていたい、と思っています。 > > そんなに複雑にはならないんじゃないかと。 > 新しい関数を追加するだけでコアには影響ありませんし。 > > sub sync_update_config(ファイル名, 関数リファレンス){ > 1)ロック > 2)ファイルから読み込み > 3)読み込んだ値を引数として関数を呼び出し > 4)戻り値を一時ファイルに書き込み > 5)リネームしてロック解除 > } > > みたいな感じで。 なるほど、関数のリファレンスを渡すのですね。 恐れ入ります。 良さそうです。 > > そういった意味では、徹底的に構造化設計されたFSWikiはとても綺麗なアプリケ > > ーションだと感じています。 > > 安全機能を極めるのもいいですが、その恩恵以上に無駄にソースが複雑になるな > > ら、私としては「あまり嬉しくないかな」って思ってます。 > > もちろん、改造コード量に見合う効果があるならその限りではありません。 > > いやいや、現在3.5のコアには過去のしがらみとかで無駄に複雑な > 部分が結構ありますよ。 いえいえ。 部分部分で見るとそういう部分もあるかもしれませんが、全体として見ると 模範的なソースです。 いろいろと勉強させて頂きました。
Fork