came to this talk before I knew what tiger beetle was - since then I have watched almost all the tiger beetle videos and looked into the code. TigerBeetle is legit - your consensus algorithm is one of the most straightforward beautiful things, the two LSM tree's built in house plus all IO optimizations plus all the memory safety are so cool. View Time Stamped replication is amazing. State replication machines and protocol aware recovery - so cool. Also, love this talk and am coming back for a second time to watch it again. Thanks!
Hum I'm not at the level required to follow this talk properly. that said, I'm glad Zig conf tackle advance topics. It's motivating to slowly understanding more about system programming.
Thanks for the video. I've worked a bit with the network API of the Zig standard library and it was somewhat confusing to me. Ended-up using a very simple poll(2) syscall and call it a day. I know it's not AT ALL efficient, but at least it's available everywhere and is pretty simple. I really hope there will be a way, someday, to make efficient network applications without having to dig into very obscure, non-portable APIs. For now, the Zig standard networking API seems at an early stage.
I always find it interesting to see that people stop at Overlapped IO when talking about non-blocking IO on Windows. APIs like Registered IO (now available for well over 10 years) and IoRing (okay, this is something new right now) are available too and are very similar to io_uring which everyone seems to talk about...
AFAIK (correct me if i'm wrong here), windows RIO requires registered buffers which wouldn't fit zig's intrusive memory model + would hit the locked memory limit on linux for general purpose use. IoRing is getting there but currently only documents/supports reads and requires windows 11.
@@kprotty6828 Thanks for the reply. I mainly wanted to make the general observation that Registered IO and IoRing were not mentioned in the talk as it seems to be the case everywhere. These APIs always seem to be overlooked. And yes, Registered IO works with physically locked buffers and I only worked with it in specific contexts where this wasn't an issue (never tried to build a library on top of it). While writes are now supported by IoRing, they are still not documented in the Win32 API (took this info from the windows-internals blog).
>Get rid of current event loop? Finally!!! To me it's currently the most unintuitive and opaque thing in zig to be forced into the event loop's pattern when making use of std. What I'd like to have is the ability to write my own (close to main) and hand STL a yield function (at compile time) which gives me back my thread immediately when called (via `suspend`). The response I'd expect from an STL-provided wait function kinda like I/O Completion Port does it. This wait function would give you incoming connections or files or cpu bound tasks even (as a tagged union) you can switch on. This can be in user space of course if possible. In practice this would mean that the user runs their own thread pool (e.g. 1 thread per logical core), each thread calling wait in a loop and handling the event when it becomes available. What I'm not sure about is how to best allow the user to integrate their own tasks. Ideally there'd be only 1 wake trigger.
Zig (stdlib) doesn't enforce the event loop but provides it as an option for those who don't want to implement their own. Zig async also operates on coroutines (stackless state machines it builds) rather than OS threads or the traditional green thread approach. It sounds like you want a cross-platform reactor instead? By running their own thread pool, would that mean multiple threads polling the same reactor? This is what Go, Tokio, and Zig's stdlib current event loop already do: You have fine grained scheduling with `Loop.onNextTick(&node_with_suspended_frame_to_resume)` and IO completions are serviced via said frames (handling and dispatching ready tasks are done inside the loop). If this doesn't sound like what you want, were you instead describing the thread-per-core architecture in the video?
Sounds like I gotta mess with it again some time - Probably when 0.10.1 drops. The way I remember it, in order to roll your own, you'd have to implement the same interface the STL event loop uses, which wasn't just yield/wait but something opinionated I couldn't become friends with and also wouldn't let me just throw my own frames in.
I would like to see a runtime with dynamic amount of io reactors. a single poll based event loop can stop to scale completely when many fd given. On the other hand thread per io reactors can be waste of resource as you don't always need io throughput.
Hey I’m new to concurrency and I’m trying to wrap my heads about all the concepts surrounding this topic. Do you have any good books or blogs or whatever so that I can understand it deeper ?
I am not nearly as deep into zig as you guys but as someone who came from outside I have to say that asyncio seems to be a big mistake imho. Zig is supposed to be "simple" but even after that shirt period of evolvment time zig seems to be more and more cluttered with optional/secondary stuff.
Great question! We were aware of it, but our philosophy is to work on commodity hardware, targeting slow/small hardware as well, and being fast like that (e.g. thinking about disk/memory access patterns). With large enough disk blocks (64 KiB) and with io_uring, performance is almost also on par, from what we have read. TigerBeetle was designed just as io_uring was out, so we were also lucky that we had the benefit of being able to target it.
