Comment by laserbeam

Comment by laserbeam a day ago

> If anything, it would make sense to me to have IO contain an allocator too. Allocation is a kind of IO too.

Io in zig is for “things that can block execution”. Things that could semantically cause a yield of any kind. Allocation is not one of those things.

Also, it’s perfectly reasonable and sometimes desireable to have 13 different allocators in your program at once. Short lived ones, long lived ones, temporary allocations, super specific allocators to optimize some areas of your game…

There are fewer reasons to want 2 different strategies to handle concurrency at the same time in your program as they could end up deadlocking on each other. Sure, you may want one in debug builds, another in release, another when running tests, but there are much fewer usecases of them running side by side.

chrisohara a day ago

> Io in zig is for “things that can block execution”. Things that could semantically cause a yield of any kind. Allocation is not one of those things.

The allocator may yield to the OS when requesting or releasing memory (e.g. sbrk, mmap, munmap)?

Reply View 4 replies

messe a day ago

I don't find that a particularly compelling argument in this case, because so can accessing any memory address if it's not currently swapped in.

Reply View | 0 replies
laserbeam 21 hours ago

Yielding in this context means to a different “thread” in your context, not the OS. If you want to express “this is a point where the program can do something else” it is a yield. If you block and can’t switch to something else… it is not.
So if you’re using an API like mmap like that you should think of it as IO (I don’t think you can, but am not sure).

Reply View | 1 reply
- throwawaymaths 20 hours ago
  
  the page allocator which is the root of many allocators calls mmap. of course the fixed buffer allocator does not.
  
  Reply View | 0 replies
[removed] 21 hours ago

[deleted]

Reply View | 0 replies