Repository navigation
core: thread tests wait on the clock, not a count of yields - #239
Merged
Merged
Conversation
"a read lands through pump" failed on a macOS runner (#234's CI) as `error.NeverLanded`. The read runs on the `Io`'s pool, and the test gave up after 200,000 yields; a yield returns at once when the other thread is waiting on the disk rather than the CPU, so that was about 20 ms of wall time on an idle Mac. A runner whose disk answered slower failed it. Delaying the read by 100 ms reproduces the failure exactly on the old test; the new one passes. The test now pumps until the read lands or 10 s pass on `std.Io.Clock.boot`, and keeps the read's error, so a failure says whether the read never landed or landed as an error (the old sink dropped the error, which read as "never landed" too). The same count-of-yields wait was in three `core/work.zig` thread-mode tests (100,000 yields, ~10 ms) and FileTable's rename onto a mount; they wait on the clock the same way. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
foxnne
pushed a commit
that referenced
this pull request
Oct 8, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Euk6iCavQdW7MG5FN2vvFw
2 of 8 tasks
foxnne
added a commit
that referenced
this pull request
Oct 8, 2026
Part of #226 ## What changes Two pieces pixi's dropper magnifier (fizzyedit/pixi#3) needs to be a clear liquid orb over its zoom, with no frost and strong refraction: native Liquid Glass on macOS, the app's glass everywhere else. And the SDK release that ships them, so the orb can be tried against `main` as soon as this merges. **`core.native_glass.offered`** - The app publishes each frame whether the OS draws glass declared outside a view drag (`publishOffered`, from `Popout.beginFrame`'s `nativeGlass()`). - A plugin that sees it declares its glass with `native_glass.add`. Fizzy's overlay of Liquid Glass already stays up while any glass is declared. - Pixi declares a clear piece (`frost = 0`, the lens alone) over a zoom it draws in the window, so the OS's lens refracts the window beneath. - Off macOS 26, or with native glass off, `offered()` is false. **`LiquidField.drawPicture` / `pictureMargin` / `lens`, and `glass_look.forLens`** - The app's glass as a lens over a picture the plugin drew. The middle is the picture as it is, with no frost, colour or lift; the rim bends and lights it. - It reads no capture, so the middle stays pixel-exact. - On the web, where no look is published, it is the earlier glass. `pictureMargin` says how far past the shapes the picture should reach for that glass's rim, at the strongest shape lens. **Tried and dropped:** pixi tried the drop zones' frosted glass with its zoom laid over it. On a Mac it read as a thick grey border or a flat rim. **Merged with main** (#234–#236, #239, #240). ## SDK impact - [ ] None - [ ] Core-only or additive: reaches plugins at the next SDK release - [ ] Fingerprint moved: recorded in `sdk/src/version.zig`, `sdk_version` untouched, PR labelled `sdk` - [x] SDK release: bumps `sdk_version`, lists the `sdk` PRs since the last `sdk-v*` tag `sdk_version` goes 0.2.17 → 0.2.18 (ef95301). Since `sdk-v0.2.17` this release carries: - this PR's core additions; - #223, #224 and #227's core (the one-slider glass, `glass_look`, `core.native_glass`, `core.screens`'s menus and dialogs). The fingerprint has not moved, so installed plugins keep loading. Merging tags `sdk-v0.2.18` and, per #240, asks the store plugins to repin. ## Verified - `zig test core/gfx/glass_look.zig`: 13 pass. - `zig fmt --check` and `zig ast-check` on the changed files. - `tests/integration.zig` compiles `drawPicture` and checks `pictureMargin`. - CI: Linux, macOS, Windows, integration and the Windows cross-build on this head. - [x] macOS: pixi's orb tried locally against this branch by the maintainer, who approved it. - [ ] Windows: - [ ] Linux: - [ ] Web: ## Follow-ups - pixi#3 repinned to `sdk-v0.2.18` once it's tagged. - The orb pinching off pixi's sample button and merging with it (the plan's next step for this consumer). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Euk6iCavQdW7MG5FN2vvFw --------- Co-authored-by: Claude <noreply@anthropic.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
1 participant
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.
What changes
Fixes the macOS failure in #234's CI:
LocalFs"a read lands through pump" failed witherror.NeverLanded. #234 itself changes onlyci.yml, and the same test passed on macOS in #234's previous run and in #228's.Cause. The read runs on the
Io's thread pool, and the test pumped and yielded 200,000 times before giving up. When the read thread is waiting on the disk, not the CPU, each yield returns at once. I measured the full budget:So a runner whose disk took more than about 20–50 ms to answer failed the test. Loading the CPU makes the test more tolerant, which is why my reproduction attempts under load all passed: 0/80 runs of the test binary and 0/15 warm
zig build testruns at background priority.Reproduced directly: with the read delayed by 100 ms, the old test fails with exactly CI's error (
NeverLandedatLocalFs.zig:393), and the new one passes.Now:
LocalFs"a read lands through pump" pumps until the read lands or 10 s pass onstd.Io.Clock.boot, and stops the moment it lands, so it's no slower when things are fast. It also keeps the read's error. The old sink dropped it, so a read that failed also showed up as "never landed". A future failure will now say which of the two it was.core/work.zigthread-mode tests (100,000 yields, about 10 ms) and in FileTable's "rename onto a mount" test. They now wait on the clock the same way, written inline at each site.SDK impact
Verified
zig build testpasses 71/71 steps and 491/492 tests (the one skip is the existinglsp-urione). The file-table tests pass 43/43 and the work tests 4/4.NeverLanded; the new one passes. The delay was temporary and is not in this diff.Follow-ups
core/FileTable.zigonmainalready failszig fmt --check. I left it alone to keep this diff to the tests.🤖 Generated with Claude Code