mirror of
https://github.com/vercel-labs/scriptc.git
synced 2026-11-01 07:33:12 +08:00
Chris Tate
d7198f016f
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.