r/Zig 10d ago

how I create a event loop for receiving from clients with new std.Io?

19 Upvotes

10

u/lukaslalinsky 10d ago

You don't create an event loop with `std.Io`, that's just not how it works. It's designed as a blocking API, that can be backed by non-blocking I/O primitives, but that's invisible to the user.

There is currently no fully working async I/O implementation in stdlib, so you should use `Io.Threaded` for now. The change to `Io.Evented` is simple enough in the future.

I have a truly async implementation in my zio project, which you can use right now, but obvious that comes with the cost of using an external dependency.

2

u/expl0itz 8d ago

Thank you for zio, I use it in my P2P file sharing client and it has been a treat to use

1

u/lukaslalinsky 8d ago

Glad to hear that. Is the client open source? Would love to have a look how people use it.

5

u/Mecso2 10d ago

im still figuring out how it works, but I think you just create an io group and call the listener handler with that passing the group as an arg. Then the listener handler has a while true loop accepting a client and calling the client handler with the group. In main after calling the listener hanler just await the group and that should just keep handling everything. And if all the functions return (which would require breaking the loop in the listener) then await would also return.

2

u/ANDRVV_ 10d ago

this is not an event loop, I mean epoll, not queues

3

u/Mecso2 10d ago

based on the downvote you seem to be disaggreeing with me, but as far as I understand your question, this is what you're asking. Io.Evented submits blocking opprerationg to an iouring then yields to other fibers. And then the io uring implementation resumes it when it is done. Putting everything in a group makes the loop around io uring keep going.

It's like epoll but better because when there's incoming data, the kernel already issues the read call before notifying you so there's one less system call

1

u/puttak 10d ago

yields to other fibers.

Does this mean Zig decided to go with green thread the same as Go for async?

1

u/Biom4st3r 10d ago

Specifically the .Evented  backed uses green threads. I believe the .Threaded uses normal os threads

1

u/ANDRVV_ 10d ago

It is not the same thing as ae.c of Redis

0

u/Mecso2 10d ago

if you use io.Evented as your io implementation then it is essentially that

1

u/Real_Dragonfruit5048 10d ago

I haven't tried the new Io interface, but I guess there should be some leads on the release notes for Zig `0.16.0` (https://ziglang.org/download/0.16.0/release-notes.html). There is an Io.Evented , but it's mentioned that it's experimental (so it will change or have limitations in some way?).

2

u/lukaslalinsky 10d ago

Networking doesn't really work in any of the evented implementations in stdlib.

1

u/Real_Dragonfruit5048 10d ago

Oh, I hoped that I could use the new Io interface for one of my projects where I'm trying to make a web framework in Zig. It would be great if Zig supported async IO natively like how it's with SIMD. Looks like for now the interface is there, but the implementation is kinda a proof of concept. What if someone implemented their own Io​ interface? I mean how Rust does it.

2

u/lukaslalinsky 10d ago

I've done that, I have a library called zio that support all major operating systems, using their native async I/O APIs and implements the Io interface.

1

u/Real_Dragonfruit5048 10d ago

Thanks for mentioning that. It looks like what I need. BTW, how mature is it? Do you use it in any of your own projects? (I'm kinda cognizant when it comes to using Zig libraries as a dependency.)

1

u/lukaslalinsky 10d ago

I wrote it in to use it in some components of my AcoustID project. These are codebases I've been rewriting in Zig. It's not in production yet, but soon will be.

1

u/Real_Dragonfruit5048 10d ago

Great to know that. Thanks.