feat!: port the core FFI tree to Zig 0.16.0

[hyperpolymath]

PR B of the BoJ 0.16 campaign

Completes the toolchain convergence for boj-server's own Zig code, matching the cartridge sweep in boj-server-cartridges#109.

The canonical shim ffi/zig/src/cartridge_shim.zig is now byte-identical to the registry's template copy and owns the 0.16 compat layer — 0.16 removed std.Thread.Mutex, std.time.*Timestamp, std.time.Timer, std.crypto.random and std.posix.getenv outright:

Removed	Shim replacement
std.Thread.Mutex	shim.Mutex over std.Io.Mutex
std.time.{nano,milli,}Timestamp, Timer	shim.*Timestamp / the Io clock
std.crypto.random.*	shim.randomBytes / shim.randomInt
std.posix.getenv	shim.getenv
—	shim.io(): one process-wide std.Io.Threaded

The three ports that weren't mechanical

• loader.zig — std.fs.File → std.Io.File. 0.16 signals end-of-stream with error.EndOfStream; a 0-byte return no longer means EOF, so the hashFile read loop would have spun or truncated silently. Caught by its own tests. Also realpath → realPathFile (returns a length now).
• federation.zig — std.net → std.Io.net; socket+bind fuse into IpAddress.bind. Non-blocking recv is receiveTimeout with a zero Io.Clock.Duration on the .awake clock — a true MSG_DONTWAIT equivalent (confirmed by reading Io/Threaded.zig: it issues recvmsg(MSG_DONTWAIT) first and only then polls). SO_REUSEADDR is dropped — BindOptions has no equivalent and the option is only meaningful before bind, which is no longer a separate call. Harmless for unicast UDP (no TIME_WAIT; port sharing would need SO_REUSEPORT).
• verisimdb.zig — process.Child.run → std.process.run, Term tags lowercased. The old term.Exited access would panic on a signal-killed child; the new switch returns the same error instead.

Pins

.tool-versions 0.15.1 → 0.16.0 and every setup-zig pin → 0.16.0. The three archived goto-bus-stop/setup-zig uses (truthfulness, lsp-dap-bsp, e2e) migrate to the mlugg action this repo already pins elsewhere.

Verification

• cd ffi/zig && zig build test → 316/316 tests across 41 steps
• E2E fixture cartridge → 17/17
• All 26 workflows YAML-parse

Beyond the suite, the federation receive path was exercised directly (loopback heartbeat received, sender address round-trips to the same peer slot, QUIC key-exchange tag) because its tests are defensively written and green alone wouldn't prove it.

🤖 Generated with Claude Code

[gitar-bot]

Note

Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime.
Learn more

Code Review ✅ Approved 2 resolved / 2 findings

Ports the core FFI tree and toolchain to Zig 0.16.0 with updated file I/O, networking, and process management. Consider tightening the hashFile loop to handle non-terminal 0-byte reads and reviewing the lazy Io thread pool mutex routing.

Auto-approved and auto-merge armed: No blocking issues found.
Please see Auto-approve Docs for details on setting custom approval criteria. — merges when pipeline and required approvals pass.

✅ 2 resolved

✅ Edge Case: hashFile loop can spin on non-terminal 0-byte reads

📄 ffi/zig/src/loader.zig:76-85
The rewritten read loop treats only error.EndOfStream as terminal and, by the author's own comment, a 0-byte readStreaming return is non-terminal. For a regular file this is fine, but if a non-regular path (FIFO/pipe/char device) is ever passed, readStreaming can return 0 without EndOfStream and the while (true) loop busy-spins forever, hanging the caller. Practically low risk since cartridge paths are regular .so files, but a defensive guard (e.g. break/yield after a run of consecutive 0-byte reads, or reject non-regular files via stat before hashing) would make it robust.

✅ Performance: Every mutex lock now routes through a lazily-built Io thread pool

📄 ffi/zig/src/cartridge_shim.zig:114-128
shim.Mutex.lock/unlock call io() on every acquisition, and the first call anywhere constructs a process-wide std.Io.Threaded (a thread pool backed by smp_allocator) that is never deinitialized. For hot lock paths (per-packet federation processing, catalogue mount/unmount) this adds an atomic acquire-load plus Io-interface dispatch per lock versus a direct futex, and pins a thread pool for the process lifetime. Functionally fine and the leak is acceptable for a singleton, but if lock contention or per-op latency matters, consider caching the std.Io handle once rather than re-resolving it on each lock/unlock.

Options

Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Compact

gitar display:verbose

---

Important

Your trial ends in 3 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more.

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

Gitar has auto-approved this PR and enabled auto-merge (configure)

✅ All code review findings resolved.

_{Configure merge blocking}