test(content): give the loader concurrency tests real concurrency
Fixing the two failures that were stopping portable-headless earlier let the job reach AcDream.Content.Tests for the first time on either operating system - the test loop exits on the first failing project, so the windows leg had never got past the apt step and the ubuntu leg had never got past Core.Net. Two RetailDatLoaderTests cases were waiting there, and they failed on both. Both assert on RawDatabase.MaxConcurrentReads after issuing two Task.Run reads that each block 40 ms in Thread.Sleep. A pair of pool work items is not a guarantee of two workers in flight: on a low-core or saturated pool the second queues behind the first, the reads run back to back, MaxConcurrentReads stays 1, and the assertion fails for a reason that has nothing to do with the loader. Pinning the suite to two CPUs on Ubuntu reproduces it 5 times in 6; Windows is clean 6 of 6 at sixteen cores, which is why nobody had seen it. The pairs now start with TaskCreationOptions.LongRunning on the default scheduler, which asks for a thread each. No assertion is changed - they still fail if the loader serialises. The two coalescing cases moved onto the same helper on purpose: two callers genuinely in flight is the situation coalescing exists for, and a sequential pair was only ever exercising a cache hit. Ten of ten clean under the same pin. Release build green. App tests 4,152 / 3 skipped. Content 124 / 124. Filed as #255. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
777f60708d
commit
c7861020e1
3 changed files with 102 additions and 12 deletions
|
|
@ -3320,6 +3320,22 @@ structural `spirv-dis` compare. The pinned NuGet native is already the pin.
|
|||
the token, which still bounds the asynchronous wait. Ten of ten clean under
|
||||
the same two-CPU pin afterwards. The test was not touched.
|
||||
|
||||
**And one the fixes uncovered.** With (3) and (4) gone, `portable-headless`
|
||||
reached `AcDream.Content.Tests` for the first time on either operating system —
|
||||
the workflow's test loop exits on the first failing project, so the windows leg
|
||||
had never got past the apt step and the ubuntu leg had never got past Core.Net —
|
||||
and two `RetailDatLoaderTests` cases failed on both. Same family again, and
|
||||
again not the campaign's: they assert `MaxConcurrentReads` after issuing two
|
||||
`Task.Run` reads that each block 40 ms, and a pair of pool work items is not two
|
||||
workers in flight. Reproduced at 5 failures in 6 under the two-CPU pin, clean 6/6
|
||||
on Windows. Both pairs now start with `TaskCreationOptions.LongRunning` so the
|
||||
concurrency the assertions measure is actually offered; **no assertion changed**,
|
||||
and the two coalescing cases get stronger for it, since a sequential pair only
|
||||
ever exercised a cache hit. 10/10 clean under the pin. Filed as #255.
|
||||
|
||||
**Net effect on the V9 row:** the job is green, and so is the whole workflow —
|
||||
its first fully green run is the evidence the row was waiting for.
|
||||
|
||||
### 5.4 The null-target `BeginPass` divergence (V4c) — ✅ DISCHARGED at V6k
|
||||
|
||||
> **Closed 2026-07-28 by V6k commit 2 (`eb7e6b4e`); see §5.5.16.** The answer is
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue