mirror of
https://github.com/euzu/tuliprox.git
synced 2026-10-18 22:03:01 +02:00
DarkBreakpoint
de73957fd4
Task 10, step 6. `PersistedMaterialization.priority` was documented as "the highest priority among the attached entries; recomputed on attach and detach rather than owned by any one of them". Nothing computed it. `split` copied whichever entry it happened to be looking at and `commit` kept the first to arrive, so the value was one arbitrary requester's. One transfer serves every entry pointing at its file. With the arbitrary value, a user who queued a film in the background could pin the transfer to the background queue while another user's foreground request for the same bytes waited behind provider capacity it should have outranked -- for a file already being fetched. `recompute_effective_priorities` derives it from the links on every commit, alongside the reference count. On read it is recomputed rather than rejected: an inconsistent reference count risks deleting a file someone still holds, while an inconsistent priority only schedules badly, so the two fail differently on purpose. The runtime had the same split. `recording_transfer` asked the active task for its own priority, so a stored effective value would have changed nothing. `active_scheduling_priority` now answers with the strongest priority among the entries sharing the active task's media, and the provider acquisition loop uses that. It takes the mutation guard first, like `committed_snapshot`, so the two cannot interleave their inner locks. Priority stays per entry in storage: it is what that user asked for, and losing the strongest entry has to relax the file rather than leave it holding an urgency nobody still wants. That case has its own test.