多重起動ガードの後始末: Ledger のコメント更新と、プロファイルをまたぐ競合の扱い

[hal-shu-sato]

背景

Ledger は同じ apm.json のインスタンスをプロセス内で共有することで、並行する read-modify-write の lost update を防いでいる（4974017e）。そのときのコメントに次の一文がある。

src/main/Ledger.ts

// apm の多重起動(プロセス間の競合)はこの方式では防げない(別課題)

この「別課題」は、その後 79deb8cd で app.requestSingleInstanceLock() が入って解決している。2 個目のプロセスは起動せず既存窓へフォーカスを渡すので、同一プロファイルでの競合は起きない。

(1) コメントが古い

Ledger.ts のコメントは、解決済みの課題を未解決として指したままになっている。読んだ人は「apm.json はプロセス間で壊れうる」と受け取るが、実際には防がれている。

index.ts 側のガードを参照する形に直したい。

(2) 残っている隙間

requestSingleInstanceLock() のロックは userData 単位（index.ts のコメントにも明記）。したがって、別プロファイルの 2 プロセスが同じ installationPath を触る構成だけは防げない。

具体的には:

• 開発起動（_Dev プロファイル）と製品版を同時に起動し、両方で同じ AviUtl フォルダを選んでいる場合
• --user-data-dir で隔離した E2E と、通常起動が同じフォルダを指す場合

どちらも 開発時に限られる構成で、一般利用者が踏む経路ではない。プロファイル単位のロックは E2E と _Dev を干渉させないために意図的にそうしているので、これを installationPath 単位のロックに変えると今度は開発が回らなくなる。

判断が要ること

• (1) のコメント修正はやるだけ。ただ (2) をどう書くかが決まらないと文面が決まらない
• (2) を「仕様として受け入れる」なら、コメントにその旨（開発時のみ・意図的）を残して終わり
• (2) を塞ぐなら、installationPath 単位のアドバイザリロック（{installationPath}/apm.lock 等）を別に持つ設計になる。実害の頻度に見合うかは要検討

個人的には (2) は受け入れてコメントに書くのが妥当だと思うが、開発中に apm.json を飛ばした経験があるなら話が変わるので、判断を仰ぎたい。

参考

• 4974017e fix(main): 並行書き込みで導入記録が消える競合を Ledger の共有インスタンス化で修正
• 79deb8cd fix(main): requestSingleInstanceLock で多重起動を防止
• fix(main): 例外で Ledger のトランザクションが開いたままになる問題を修正する #2433 で Ledger のトランザクションが例外で開いたままになる問題を修正した際、この領域を一通り読んで気づいたもの