←back to thread

lsr: ls with io_uring

(rockorager.dev)
335 points mpweiher | 4 comments | 18 Jul 25 12:40 UTC | HN request time: 0.23s | source
Show context
quibono ◴[18 Jul 25 13:45 UTC] No.44604587[source]▶
Lovely, I might try doing this for some other "classic" utility!

A bit off-topic too, but I'm new to Zig and curious. This here: ``` const allocator = sfb.get();

    var cmd: Command = .{ .arena = allocator };
``` means that all allocations need to be written with an allocator in mind? I.e. one has to pick an allocator per each memory allocation? Or is there a default one?
replies(2): >>44604650 #>>44604736 #
1. IggleSniggle ◴[18 Jul 25 14:01 UTC] No.44604736[source]▶
Caveat emptor, I don't write Zig but followed its development closely for awhile. A core design element of zig is that you shouldn't be stuck with one particular memory model. Zig encourages passing an allocator context around, where those allocators conform to a standardized interface. That means you could pass in different allocators with different performance characteristics at runtime.

But yes, there is a default allocator, std.heap.page_allocator

replies(3): >>44605558 #>>44606092 #>>44606190 #
2. hansvm ◴[18 Jul 25 15:12 UTC] No.44605558[source]▶
std.heap.smp_allocator

You should basically only use the page allocator if you're writing another allocator.

3. SkiFire13 ◴[18 Jul 25 15:48 UTC] No.44606092[source]▶
> you shouldn't be stuck with one particular memory model

Nit: an allocator is not a "memory model", and I very much want the memory model to not change under my feet.

4. throwawaymaths ◴[18 Jul 25 15:55 UTC] No.44606190[source]▶
> Zig encourages passing an allocator context around, where those allocators conform to a standardized interface.

in libraries. if youre just writing a final product it's totally fine to pick one and use it everywhere.

> std.heap.page_allocator

strongly disrecommend using this allocator as "default", it will take a trip to kernelland on each allocation.