各ファイルを更新する際の処理に排他制御を導入 #52
No reviewers
Labels
No Label
bug
discussion
documentation
duplicate
enhancement
feature
help wanted
invalid
Priority
High
Priority
Low
Priority
Medium
question
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: stat2/delightly-v2fork#52
Loading…
Reference in New Issue
No description provided.
Delete Branch "konkon-fox/delightly-v2fork:bugfix/mutual-exclusion"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
概要
現在のコードでは
$THREADFILE
、$DATFILE
、subject.json
等のファイルの読み込み及び書き込み処理にfile_get_contents
及びfile_put_contents
を使用しており、複数処理が同時に行われた際にファイルが正しく読み取れなかったり破損する恐れがあります。したがって排他制御を用いたファイルの更新方法に変更する必要があります。
行ったこと
ファイルの更新方法を
fopen
=>flock(LOCK_SH or LOCK_EX)
=>fread
=>(編集)
=>(fwrite)
=>fclose
という処理に変更しています。共有ロックか排他ロックかの選択に関しては、ファイルや処理の都合に合わせて適したものを選んだつもりです。
各ファイルについて
$THREADFILE
&$DATFILE
通常は追記モードで開き、共有ロックを取って追記しています。
コマンド使用で
>>1
に変更がある場合には排他ロックを取って全体を書き換えています。subject.json
&subject.txt
どちらも排他ロックを取って全体を書き換えています。
HAP
ファイルこちらは自身しか操作しないはずですが一応排他制御を導入しました。
情報を取得する際には共有ロックで開いて一旦閉じます。書き換える際には再度排他ロックを取って全体を書き換えています。
TL(index.json, dat)
どちらも排他ロックを取って全体を書き換えています。
投稿ログ(LOG.cgi)
通常は追記モードで開き、共有ロックを取って追記しています。
ログ数超過で縮小処理がある場合には排他ロックを取って全体を書き換えています。
参考:#42
スレ状態($threadsStates)の取得
共有ロックを取って読み込んでいます。
過去ログ用
subject.json
排他ロックを取って全体を書き換えています。
別の変更点
!
が本文中に含まれるだけで>>1
の変更フラグ($reload
)が立っていたので!add
のみに変更しました。なお
!chtt
等の追加コマンドでは個別で$reload
をtrue
にする処理が含まれています。変更していない点
今回の変更は掲示板の主な機能が損なわれるのを防ぐために行ったので、規制関連のファイル更新には手を付けていません。
しかし同様の問題が存在するので、今回の修正が上手くいくようなら規制関連のファイル更新処理の修正も同様に行いたいと考えています。
〆
排他制御を導入したことにより、パフォーマンスが落ちる可能性が生じます。具体的には書き込みが遅くなったりする恐れがあります。
どれほどの影響があるかは私の手元の環境では予想不可能なので出来るだけ書き込む人の多い環境でテストいただければありがたいです。
また、ご質問やご指摘があればどうぞお知らせください。
Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Gitea.