error.WouldBlock thrown

[marijnfs]

When running the async example, an error.WouldBlock is thrown by the accept() function.
It seems that this either means some issue with the event loop, or that accept also has a suspend in it?
I tried putting the accept() in the Client.handle() function and then it works, but with the current code this means a continuous stream of clients is created since it doesn't block.

How would one keep the accept blocking, but still make the rest of the code async?

zig-network git:(master) ./zig-cache/bin/async 
listening at 0.0.0.0:2501
Waiting for connection
error: WouldBlock
/usr/local/lib/zig/std/os.zig:3041:27: 0x256ade in std.os.accept (async)
                EAGAIN => return error.WouldBlock,
                          ^
/home/marijnfs/software/zig-network/network.zig:368:20: 0x2518bd in .network.Socket.accept (async)
        const fd = try accept4_fn(self.internal, addr_ptr, &addr_size, flags);
                   ^
/home/marijnfs/software/zig-network/examples/async.zig:26:21: 0x250db8 in main (async)
            .conn = try server.accept(),
                    ^

[nandor-magyar]

Hey, I was looking at this code, I found that changing the io mode to blocking eliminates the error and might be ok for the sake of the example, with emphasis on the blocking behavior.

From Zigs docs:
This error occurs when no global event loop is configured, and accepting from the socket would block.
So this seems to me that some threading is needed to let it go async (std loop?), is this correct?

[ikskuh]

Hey, I was looking at this code, I found that changing the io mode to blocking eliminates the error and might be ok for the sake of the example, with emphasis on the blocking behavior.

This would completly defy the concept of the async example though.

@marijnfs on which platform does this error happen? which zig version did you use?

@alexnask you did the original async stuff, can you take a look at this?

[nandor-magyar]

The same phenomenon brought me here. I am on Arch Linux, Zig version: 0.8.0-dev.2065+bc06e1982.

[nandor-magyar]

        const fd = blk: {
            if (std.io.is_async) {
                const loop = std.event.Loop.instance orelse return error.UnexpectedError;
                break :blk try loop.accept(self.internal, addr_ptr, &addr_size, flags);
            } else {
                break :blk accept4_fn(self.internal, addr_ptr, &addr_size, flags);
            }
        };

I added this to the accept method, keeping the original async example, this worked. However, I am not so sure if this fits well. I would happily open a PR and add modifications if need be.

Neat lib anyway. 👍

[ikskuh]

I added this to the accept method, keeping the original async example, this worked. However, I am not so sure if this fits well. I would happily open a PR and add modifications if need be.

That sounds like the right thing to do. PR it in, if you have tested it and it works :)

[marijnfs]

This does indeed avoid the block error! However the frame is never resumed, so the message is not printed when you send something. I made another pull request to the async.zig example for the previous code (with the WouldBlock error) where I added a manual suspend/resume setup. I think the async example would somehow need to be updated like this.

[marijnfs]

I added the same step that nandor uses to recvfrom and then the async example works.

[ionspin]

It seems that the fix this issue was overwritten/reverted by a force push at some point, this is the current master:
https://github.com/MasterQ32/zig-network/blob/b9c52822f3bb3ce25164a2f1f6eedee4d1c0a279/network.zig#L374

Reapplying Nandors solution fixes the problem.

Edit: My bad, it was never merged.