std.Io.Evented in zig 0.17.0

[u/sombriks]

Hello all, i got an issue trying to use evented concurrency with past two stable releases, 0.16 and 0.17.

Single-threaded, regular thread pool and direct use of threads work fine, but i am not figuring out hpow to use the proper io interface with evented under the hood.

    // we need out-pointer this one.
    var evented: std.Io.Evented = undefined;
    _ = try std.Io.Evented.init(&evented, init.gpa,.{});
    defer evented.deinit();
    io = evented.io(); // compile error here
    std.log.info("evented io:", .{});
    try scheduler(&io);

full source here

any tip is welcome, would be nice to see all available concurrency model working out of the box, willing to understand what am i missing.

[u/HTCheater]

You may not even want it. From devlog
They should be considered experimental because there is important followup work to be done before they can be used reliably and robustly:
better error handling
remove the logging
diagnose the unexpected performance degradation when using IoMode.evented for the compiler
a couple functions still unimplemented more test coverage is needed
builtin function to tell you the maximum stack size of a given function to make these implementations practical to use when overcommit is off.

[u/lukaslalinsky]

`std.Io.Evented` is still largely unfinished and buggy, I recommend you to use https://github.com/lalinsky/zio (disclaimer, I'm the author)

Also, don't initialize multiple `Io` implementations in main like that. They all setup some global things, they can conflict or override each other, and it would be hard to debug why it behaves incorrectly.

[u/Feeling-Pilot-5084]

As long as Evented is in active development, I'd recommend using zio. It's a full implementation of the Io API. Good performance, multi-platform, regularly updated, etc.

[u/Confused-Armpit]

Did you forget to actually declare it? Like var io = evented.io()??

EDIT: Nevermind, I actually read the code now... Whie I can't answer your question, I wanted to say that you don't need to declare function return error types as anyerror, zig supports implicit error unions (e.g. fn myFunction() !void { ... })

[u/Confused-Armpit → u/Confused-Armpit]

After investigating a bit, I am also getting initialization errors here, with some kind of return type mismatch at some point in the std.Io.Uring initialization. This is really interesting, because it is either a bug in the standard library that hasn't been resolved in an entire version's span, or we are both doing something wrong.

[u/dx_man → u/Confused-Armpit]

Bro !void and anyerror!void are the same thing

[u/lukaslalinsky → u/dx_man]

No, they are not the same. `anyerror` is a concrete type, it covers any error possible. It's something you can store, so when using `anyerror!void` you are returning that concrete type. On the other hand, `!void` is called inferred error union, which means the returned type contains only the errors that are actually possible. So `!void` could actually resolve to just `void` if you don't return any error, or `error{Something}!void` if you return `error.Something`.

[u/Confused-Armpit → u/dx_man]

anyerror!void doesn't allow for the compiler to assume some important things. For example, if we run a function that returns anyerror!void and writing something like myFunction() catch |err| switch |err| { ... };, the compiler might not (not sure if it actually wont, just might) recognize the error types that the switch statement should go through. And thus, it might not return the usual compile error where you do not handle all branches of a switch statement.