feat: add WatchLock to coordinate rebuilds with external readers#34
Merged
Conversation
yozhgoor
changed the title
yozhgoor
changed the title
cecton
requested changes
Apr 24, 2026
Member
There was a problem hiding this comment.
In general: avoid adding pub "because I need it in xtask-wasm", think about what you want to expose or not in your public facing API (especially in libraries!). The more you expose, the more you have to maintain for stability. Any change to anything exposed forces you to make a major release because you are breaking the API contract.
Think of it as a contract you sign with someone. If you want to change it, you first need to break the contract with them before establishing a new one that replaces the old one. Otherwise you end up with 2 parties just acting with what they believe is the contract but they are not on the same page.
yozhgoor
changed the title
cecton
reviewed
Apr 24, 2026
yozhgoor
commented
Apr 25, 2026
cecton
reviewed
Apr 25, 2026
cecton
changed the title
…fy Mutex invariants
cecton
changed the title
cecton
added a commit
to rustminded/xtask-wasm
that referenced
this pull request
Apr 25, 2026
## Summary - Obtain the shared `WatchLock` from the configured watcher before spawning the watch thread - Pass the lock into the HTTP serving loop - Acquire a read guard per request, after parsing the header, so file reads cannot race with rebuild writes - Re-export `WatchLock` and `WatchLockGuard` from `xtask-wasm` so consumers don't need a direct `xtask-watch` dependency to name the types - Document why `read_header` is intentionally called before acquiring the lock (connections are accepted and headers parsed during a build, reducing response latency once it finishes) ## Why Without coordination, a browser refresh mid-rebuild could receive incomplete or inconsistent dist artifacts. Using the shared watcher lock ensures the dev server only serves files once the current build has fully written its output. Closes #80 Requires rustminded/xtask-watch#34 --------- Co-authored-by: Cecile Tonglet <cecile.tonglet@cecton.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
WatchLock/WatchLockGuardtypes for coordinating rebuilds with external readers (e.g. HTTP handlers)Watch::lock()to retrieve the watcher's shared lock handleWatch::run()holds the write lock for the entire duration of each command sequence — readers callingWatchLock::acquire()block until the build finishes, including the very first oneCommandSucceededmessages from a killed build are ignoredWatch::lock()andWatchstructWhy
Allows consumers such as dev servers to block file-serving while a rebuild is in progress, without serving stale or mid-write artifacts. The lock handle is cloneable and
Send + Sync, so it composes naturally with threaded HTTP handlers.Related to rustminded/xtask-wasm#81