Correct Initialization of Io.Evented?

[jdevries3133]

Is this the right way to construct Io.Evented?

var ev: std.Io.Evented = undefined;
try ev.init(
    alloc,
    std.Io.Evented.InitOptions{
        .backing_allocator_needs_mutex = false,
    },
);

Using zig 0.16.0-dev.2962+08416b44f.

[jdevries3133]

For a bit more context, I’m working on a minimal segfault repro related to Io.Evented here: https://codeberg.org/jackdev/mdt/src/branch/segfault_repro/scripts/segfault_repro.sh. But I’m still in the stage of trying to narrow down whether it’s an issue with my usage.

[jdevries3133]

I’m suspicious of the way I allocate futures on the heap as well for potentially being wrong: https://codeberg.org/jackdev/mdt/src/commit/1fd89ca8e94d13f89b2dbb75a7f1e97e027f6d6d/src/href_extractor.zig#L10-L17.

[vulpesx]

Assuming alloc is thread safe (it is), your options are fine.
Just checked, you are using an arena allocator, which is not thread safe. Either use a different allocator, or don’t disable evented’s mutex

fyi: std.Io.Evented.InitOptions can be replaced with a . to infer the type. Assuming you didnt know. If you just prefer that its fine.

@jdevries3133

I’m suspicious of the way I allocate futures on the heap as well for potentially being wrong

Yes it is very suspicious, looking at this, most of your allocations are unnecessary.

None of the futures or awaited results need to be allocated individually, and you can reduce to one array list by passing a ptr to the array list and a mutex to each task. Though that may be slower, benchmark if you care.

[Sze]

@vulpesx

Just checked, you are using an arena allocator, which is not thread safe.

std.heap.ArenaAllocator was made thread safe recently.

The Allocator implementation provided is threadsafe, given that child_allocator is threadsafe as well.

Some related discussion:

Do we really need a thread-safe ArenaAllocator by default?

I noticed that the ArenaAllocator in the master branch has been changed to a lock-free thread-safe implementation. I have serious concerns about this change, so I would like to get more explanation. Although I am a heavy user of ArenaAllocator, nearly 99% of my usage needs are on a single thread. I mainly use ArenaAllocator to amortize the allocation and deallocation overhead of the global allocator (including the thread-safety overhead of the global allocator) and to improve cache locality. Th…

[MikeHua]

ArenaAllocator is really threadsafe?

But I still see some “Not threadsafe” comments in the source code.

https://ziglang.org/documentation/master/std/#src/std/heap/ArenaAllocator.zig

[Sze]

I think it is thread safe when you are using the arena through the std.mem.Allocator interface.
Those comments mark methods you don’t directly access via the interface.

You can’t really deinit a data structure and expect to still be able to use it from another thread (except when using functional/immutable/persistent/multi-version data structures), so it makes sense that there would be some methods which are threadsafe and others which aren’t.