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

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

> Code that's meant to be pinned (and may behave incorrectly if not pinned) looks no different from any other code. Same goes for async/await. The decision to keep you running on the same native thread is up to the scheduler. > Java isn't positioned as a high-level, high-abstraction language and that's not, IME, the user community it has. I beg to differ. It aims to be a good compromise between productivity, observability and performance. Every choice, from JIT to GC, is about improving performance for the common case while helping productivity, not improving performance by adding fine-grained control. There are a few cases where this is not possible. Primitives is one of them, and, indeed, 25 years later, we're "expanding" primitives rather than find some automatic way for optimal memory layout. > It's always been advertised as a safer alternative to C++ - rather like Rust. I think you're mistaken, and in any event, this is certainly not our position. Java is designed for a good blend of productivity, observability and performance, and unless the circumstances are unusual, it opts for improving common-case performance with high abstractions rather than worst-case performance with low abstractions like C++/Rust. Roughly speaking, the stance on performance is how do we get to 95% with the least amount of programmer effort. Anyway, regardless of what I said above, the constraints on the design of usermode threads other than philosophy are also very different for Java than for C