mirror of
https://github.com/storytold/lightcraft.git
synced 2026-11-13 09:20:07 -06:00
2ddb43896b
* PERF-STEP-STALL: stepping and flagging never wait for the drive; the catalog log is written and synced by its own thread, and nothing handed to it is ever dropped On Windows a write to the catalog log waited for a sync of the same file in flight, and each flag, rating or step synced on the UI thread, so culling on a busy drive froze the window. FsStore now hands log appends to a thread that writes and syncs them in order, batching what arrives during a sync. No change is lost: the thread keeps every byte it has not yet synced. A write or sync that fails is held and retried (cutting any fragment first), later appends are refused with the reason (the engine keeps them queued, as for any failed save), the held records count as unsaved so the quit prompt warns, and a snapshot is made due. Cuts, replaces and reads act on the logical log (synced bytes plus held ones), so the log never has a gap. A clean quit's closing snapshot holds everything; dropping the store waits for the thread. Tests drive a slow drive (a sync hook that sleeps) and a failing one through test-only fault hooks (doc-hidden, keyed by library folder): with 300 ms syncs the slowest flag is 0.2 ms (305 ms with the log written on the caller, as before); every change made during slow saves reopens after a flush, a drop and a close; a failed write is reported, retried and lands with no gap. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * PERF-STEP-STALL: review fixes: a reopen reads what the log thread was handed, the quit check reads the held status now, a covering snapshot clears it, a cut to the synced length reaches the file - open_stores flushes the old journal's log thread before the same library's files are read again (Settings, Libraries; a reopen). - Session::refresh_unsaved, called by the quit check, reads what the log thread holds at that moment, not as of the last frame. - Journal::unwritten is None once a snapshot holds every op (the closing snapshot after a failed log reset no longer makes the quit prompt say changes would be lost); wants_snapshot follows it. - A cut to exactly the synced length with bytes held cuts the file, so bytes a failed sync left there never come back on the next open. - A caller that waits over a minute for the drive gets a timed-out error, not "the writer stopped". Each fix has a test that fails without it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * PERF-STEP-STALL: a reopen and the quit check wait for what the log thread was handed Review of #3557: - Opening the same library again while its log thread can't write what it was handed now fails and keeps the open library (with the held change, retried). Before, the new catalog was read from files missing it. - The quit check flushes the log thread first instead of reading only the failure it had already reported. A change accepted but not yet written, then failed, is saved by the closing snapshot before the window may close; if that fails too, the unsaved prompt shows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * PERF-STEP-STALL: a reopen goes ahead when the snapshot already holds every change Review of #3557: the reopen was refused whenever the old log's flush failed. When a completed snapshot covers every op, nothing is missing from the files, so the open now goes ahead and only logs the error. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> Co-authored-by: FredApps <153173854+FredApps@users.noreply.github.com>