Zig's std.Io.Threaded is a concurrency implementation that uses blocking syscalls while fully supporting cancellation. The post explains why cancellation is fundamental to concurrency (not just a nice-to-have), then details how Io.Threaded achieves it on POSIX using a signal+flag protocol: a canceling thread sets a shared-memory flag and repeatedly sends a signal to interrupt the blocked syscall via EINTR, which the cancellee checks before retrying or acknowledging. On Windows, the more direct NtCancelSynchronousIoFile is used. The post contrasts this with Java's thread interruption (which doesn't reach syscalls) and pthread_cancel (which lacks language-level integration and tears down the whole thread). Zig's Io interface also cleanly separates 'may run concurrently' (io.async, infallible) from 'must run concurrently' (io.concurrent, fallible), backed by a thread pool with fresh-thread fallback.
Questions this post answers
How does Zig's std.Io.Threaded cancel a thread blocked inside a blocking syscall?
Io.Threaded uses a POSIX signal-plus-flag protocol. The canceling thread sets a flag in shared memory, then repeatedly signals the target thread until cancellation is acknowledged. The signal causes the blocked syscall to return EINTR; the cancellee checks the shared flag and either retries the syscall or acknowledges cancellation and begins unwinding. On Windows, the more direct NtCancelSynchronousIoFile API is used instead. Developers working with Zig concurrency track Io interface changes like these on daily.dev.
What is the difference between io.async and io.concurrent in Zig's Io interface?
io.async means a task 'may run concurrently' and is infallible — it never fails to schedule. io.concurrent means a task 'must run concurrently' and is always fallible, because spawning a thread can fail. Concurrent tasks are backed by a thread pool, falling back to spawning a fresh thread only when the pool is exhausted. This separation makes signatures more precise and intent clearer. Systems developers choosing between Zig concurrency primitives find the latest Zig ecosystem discussions on daily.dev.
Why doesn't pthread_cancel work well as a language-level cancellation mechanism?
pthread_cancel lacks integration with language-level constructs like try and defer, making post-cancellation cleanup cumbersome. It also tears down the entire thread, which is costly because thread creation is slow and OS thread limits are typically low. Pooling threads is therefore preferable, but pthread_cancel's whole-thread teardown makes that impractical. Engineers evaluating threading models for systems software follow these trade-off discussions on daily.dev.