You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Address the download-lock review items:
- Per-model in-process lock. Replace the single global download_mutex_ with a
per-model mutex keyed on the resolved cache path. Two downloads of the same
model serialize; downloads of different models run concurrently in-process
instead of queuing behind each other's (up to 3 h) cross-process waits.
- Close the POSIX flock()+unlink() orphan-inode race. After flock() succeeds,
verify (fstat vs stat) that the inode we locked is still the file at the lock
path; if a racing releaser unlinked it and a third process recreated it, drop
the stale lock and report contention so the caller retries. This makes the
self-cleaning unlink-on-release provably safe and guarantees two processes can
never both believe they hold the lock - so a model can never be downloaded to
the same directory twice at once, across any number of processes or apps.
- Fix the misleading Windows ACCESS_DENIED comment: it is the DELETE_ON_CLOSE
delete-pending window (STATUS_DELETE_PENDING), not "narrower access rights".
- Document why the POSIX unlink-before-close is safe (fresh-fd non-blocking
waiters; no work between unlink and close; the inode check above).
- Decouple the lock-wait cadence from the progress heartbeat: poll the
cancellation/heartbeat callback once per poll_interval instead of every
100 ms, so a user callback is not invoked ~10x/s for the whole wait.
- Tests: add ConcurrentDownloadsOfDifferentModelsRunConcurrently (proves
different models do not serialize). Existing same-model serialize and
CrossProcessFileLock acquire/release/wait/cancel/timeout tests still pass
(66 download-suite tests green; POSIX branch syntax-checked under g++).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
0 commit comments