Zig Devlog 
io_uring and Grand Central Dispatch std.Io implementations landed
24 Likes
woohoo! i was just kicking the tires with std.Io yesterday hoping Evented might already be further along 
I was just checking the code and I can’t tell if I’m seeing this right. Is it really allocating 60MiB stacks?
1 Like
This from the Devlog makes it seem like they are over allocating and relying on the Linux kernel to handle the overcommit:
- builtin function to tell you the maximum stack size of a given function to make these implementations practical to use when overcommit is off.
It seems like an excessive amount, but with overcommit, it shouldn’t take up the full 60MiB.
This is a standard practice, even Javascript supports it. Basically, you mmap() a large chunk of memory as .PRIVATE without any file back off, so they are never written to the disk. On the very first write, a page gets allocated by the OS, mapped onto RAM address, and gets filled with zeroes (guaranteed). It can be used for the stack, so you can continue growing your stack one page at a time.
In JavaScript, you create an ArrayBuffer with reserved (uncommitted) space, and you can .resize() it to claim the RAM pages as your needs grow. The API is simpler than libc’ mmap(), and it’s automatically garbage collected.
1 Like
Not 100% sure - but I think with BSD, you can overcommit quite happily too, provided there is sufficient room in ram + swap .. so having big swap available becomes important.
Darwin gets weird though, as it tries to aggressively compress allocated memory
really excited to be able to start playing around with std.Io.Evented on macOS!
for funsies i’ve been wanting to write a trio-inspired asynchronous i/o library for Lua, and I think std.Io is ready for me to start hacking!
3 Likes