kprotty/zap

An asynchronous runtime with a focus on performance and resource efficiency.

zap

Designing efficient task scheduling for Ziglang.

Goals

So I originally started this project around 2019 in order to develop memory, threads, io, and synchronization primitives for Zig given they were lacking at the time. Over the months, it shifted more on developing a runtime (or thread pool rather) that was both resource efficient (one of Zig's, and my personal, implicit Zen's) and competitive in performance with existing implementations.

Here lies the result of that effort for now. There's still more experimenting to do like how to dispatch I/O efficiently and the like, but I'm happy with what has come and wanted to share. You can find a copy of the blogpost in this repo, the reference implementation in src, and some of my previous attempts in their own branch.

Benchmarks

To benchmark the implementation, I wrote some quicksort implementations for similar APIs in other languages. The reasoning behind quicksort is that it's fairly practical and can also be heavy with concurrency. Try running them locally!

zap's Issues

Unable to run Zig benchmark

With 0.8.1

./build.zig:15:20: error: no member named 'path' in '[]const u8'
        .path = .{ .path = "../../src/thread_pool.zig" },

Consider setting default branch to “blog”

When visiting the repo, I was initially browsing the default branch, “master”, but the “blog” branch is much more recent. Promoting the “blog” branch to the default branch in the repository settings could improve discovery for new visitors.

Thanks for this implementation and detailed discussion in the blog article.

Tasks and Nodes

Hi,

I'm trying to understand the code and I was wondering. What is the relation between a Task and a Node. I don't understand why tasks have nodes members. Is it because Queue and Buffer take Node structs instead of Tasks?

What is the rationale behind that design choice?

My understanding is as follows:
I see that in async.zig you create a wrapper around a Task with a frame member. Is wrapping tasks into our own structs the way to go to use your thread pool? And in that case, maybe it's why you are using Nodes, because you cannot have knowledge of the "wrapping struct" when dealing with popping or pushing into Queue/Buffer.

I hope I'm clear... and sorry to dig up an old project of yours xD