xsync.zig

This project implements a new set of synchronization primitives that work across std.Io instances.

std.Io.Mutex and friends wake waiters through whichever Io the waker happens to run on. That works when everything shares one parking implementation, but a waiter parked through one Io is invisible to another, so primitives can’t be shared between tasks living on different runtimes. The primitives here remember which Io each waiter parked through and wake it through that one.

Additionally, std.Io.Condition is unsafe to use in cancellation (see https://codeberg.org/ziglang/zig/issues/36139) which in turn makes std.Io.Queue, std.Io.Semaphore and std.Io.RwLock also unsafe. This library avoids the issue and is always cancellation-safe.

See this for the background:

Supported Zig versions

Zig 0.16 and master.

AI / LLM usage disclosure

I used Claude Fable 5 as a coworker, old school XP-style pair programming. Initially had it adapt my previous code from zio, then later we benchmarked it, I had some ideas how to restructure the primitives to avoid the new bottlenecks and once again, we worker on the implementation, me watching every line being written and providing my feedback. I’ve worked like this with real people, years before LLMs existed, so it’s a familiar process to me. I’ve always been the one with ideas and someone else was typing the code.

g41797 July 14, 2026, 11:11am 2

For that kind of a project I use tag ‘headmade’.

Cancel for Queue may be optional.
Consider adding of
wakeup as special operation

I do like that! :slight_smile:

It’s safer to use Queue as a base for implementing custom synchronization. It’s already close to the ideal form. I guess this is why Go developers try to get developers to synchronize using channels instead of lower-level primitives.