Modeling Data Concurrency w/ Asynchronous I/O in Zig - RedisConf 2020

There is an interesting approach in Zig to explicitly kick call frames to achieve colorless asyncness. this video

I recently wrote an IO abstraction over io_uring using Zig's async/await. Here's how you would do a write()/fsync()/read() with this ( link ): const offset: u64 = 0; const bytes_written = try io.write(fd, buffer_write[0..], offset); try io.fsync(fd); const bytes_read = try io.read(fd, buffer_read[0..], offset); Other sync functions can use this asynchronous IO completion code in a synchronous style (as this snippet shows) and still get all the zero-syscall and asynchronous performance of io_uring. What this is actually doing under the hood is filling SQEs into io_uring's submission queue ring buffer and then later reading completion events off io_uring's completion queue ring buffer, so it's fully asynchronous in the I/O sense but this hasn't spilled out and leaked over into the control flow. The control flow is as it should be, nice and simple and synchronous. Beyond this, Zig still allows you to explicitly indicate concurrency with the `async` keyword, for example if you wanted to run multiple async code paths concurrently. But the crucial part is that Zig's async/await does not force function coloring on you to do all of this: this video Pretty incredible on Zig's part to be able to pull this off. Huge kudos to Andrew Kelley. Also, thanks to Jens Axboe and io_uring, what you saw above was first-class single-threaded or thread-per-core, there's no threadpool doing that for you, it's pure ring buffer communication to the kernel and back, no context switches, no expensive coor