From d7198f016f1738b4e8270afb95eaebc39b536c8c Mon Sep 17 00:00:00 2001 From: Chris Tate Date: Wed, 28 Oct 2026 01:47:01 -0500 Subject: [PATCH] Treat the zlib ordering program as a timer race g05-zlib starts a zlib.gzip from a 0 ms island timer and arms a 2 ms timer on the native side. The 0 ms timer's callback runs before the 2 ms timer is due, so the gzip job races that timer: if the job completes on libuv's thread pool before the timer's turn, its callback runs first. Node orders the two the other way only because its first gzip usually takes longer than the wait. With zlib already loaded and the thread pool started, Node prints i-zlib first in about a quarter of runs. On fast macOS hosts the native runs took the other order. Mark it `// @order: race`, as g01 (fs), g03 (child process) and g04 (dns) already are, so its native runs must produce the lines of one of Node's outputs in any order, and name thread-pool work among the races the harness describes. --- tests/corpus-node-islands-order/g05-zlib/main.ts | 1 + tests/harness/node-island-order.test.ts | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/tests/corpus-node-islands-order/g05-zlib/main.ts b/tests/corpus-node-islands-order/g05-zlib/main.ts index 14abe51b1..3a4c9fac9 100644 --- a/tests/corpus-node-islands-order/g05-zlib/main.ts +++ b/tests/corpus-node-islands-order/g05-zlib/main.ts @@ -1,4 +1,5 @@ // @requires-libnode +// @order: race // X { T 0 { Z { L i-zlib } } } T 2 { B 80 L h-sync } import { callSync } from "@scriptc/node"; import { readFile, writeSync } from "node:fs"; diff --git a/tests/harness/node-island-order.test.ts b/tests/harness/node-island-order.test.ts index 5d4aa96a1..1f86babac 100644 --- a/tests/harness/node-island-order.test.ts +++ b/tests/harness/node-island-order.test.ts @@ -13,7 +13,9 @@ * A program whose head says `// @order: race` races a timer against I/O * whose duration differs between the sides (scriptc's own fs callbacks * complete in one turn where Node's readFile takes several; module loading - * on the first call into Node takes longer than in a Node process), or two + * on the first call into Node takes longer than in a Node process; a job on + * libuv's thread pool, such as zlib's, can finish before or after a 2 ms + * timer depending on the host), or two * equal timers armed on either side of an island call, which a millisecond * boundary between them (likely in a sanitized build) puts in different * loop turns, so Node permits orders it rarely produces in M runs. Its