well, each posted SQE generates one CQE in the linked requests chain, i don't want to have the linked_timeout generate its own CQE, it seems a bit redudant since i'm getting the ECANCELED in the recv result anyways

this is also partly why i didn't want to deal with two CQEs, on failure (timer fired), you get the timeout cqe and then the recv cqe, on success you get the opposite

Using liked timeouts for recv is a good MVP but I wouldn't commit to this forever, because it doesn't work as well with multishot timeouts

Your end-goal would probably be just copy-pasting a timer wheel impl and shoe-horning that in

Linked timeouts, ime, don't always have the best perf

I remember getting thrashed when using liked timeouts with send()

That all being said, I use linked timeouts for connect(), and that's probably just going to say that way because connect() is something you only call once

multishot timeouts?

Oh sorry, I meant recv

was thrown off guard for a bit thinking this was elixir lol

interesting, i'll dig into this a bit more later, i'm currently using the linked timeout during a small part of the method negotation with the client and during the connect to a server so it's not too bad

Did you forget that you set the flag there?

What flag?

IOSQE_CQE_SKIP_SUCCESS

Waht do you mean? It just doesn't generate a CQE on success

Maybe it's useless, I don't know

The user_data is null'd out anyway, so my CQE processing would skip it anyway

In your first reply you said that you thought that linked timeouts only generated 1 cqe, I thought you meant 1 cqe for the operation being timed out and none for the linked_timeout itself by default. Which is not the case, both have their distinct CQEs that need to be dealt with. That's why i asked whether you forgot that you set IOSQE_CQE_SKIP_SUCCESS since that suppresses the linked_timeout cqe and gives the impression that only 1 CQE is generated by default...

Yeah, i was just wrong

I corrected myself like two messages down from that

I also had the same belief about calling

close

on socket that has a pending

recv

, I got this from using golang where it's normal to call conn.Close() from another goroutine to stop the reading/writing.... It just hangs like the

accept

you mentioned.

TIL you can shutdown an accepting socket too...

and makes me wonder what setting receive / send buffer sizes does to it....

Well, elixir is also heavily inspired by ruby so it is not that far off. Though crystal is more fun

Wow, it's already been like 2 years lol

Age is hell. Time only moves faster

it's also interesting that you need to set the

how

argument to

SHUT_RD

or

SHUT_RDWR

but not

SHUT_WR

for it to cancel the

accept

.

$ zig run accept_client.zig 
info: accepting clients on 7788
warning: shutting down the accepting socket 4 with how value .SHUT_WRITE
info: shutdown: .{ .user_data = 2, .res = 0, .flags = 0 }, cqe.res: 0

This is not something i expected, shouldn't the res field contain an errno here 🤔

Not for jens it seems ....

I've been experimenting a bit with

io_uring_prep_shutdown

to see how it interacts with various other io operations. i set up this tcp server which accepts a client, sends it 1mb, then closes the socket. the client on the other hand, connects, waits for enough milliseconds to allow the socket to fill up with the 1mb of data, then shuts down the socket's read side, and starts issuing `io_uring_prep_recv`s. And during the reaping of CQEs I get these:

info: recv: .{ .user_data = recv, .res = 128000, .flags = 4 }
info: recv: .{ .user_data = recv, .res = 95232, .flags = 4 }
info: recv: .{ .user_data = recv, .res = 411136, .flags = 4 }
info: recv: .{ .user_data = recv, .res = 285696, .flags = 4 }
info: recv: .{ .user_data = recv, .res = 128512, .flags = 4 } // received EXACTLY one MB up to here.
info: recv: .{ .user_data = recv, .res = 0, .flags = 4 }

the flags = 4 is for

IORING_CQE_F_SOCK_NONEMPTY

which i found strange in the last CQE with res = 0 since there is no more data to read but it made me suspect that the server closing the socket is probably what's causing it, and it turns out my intuition is correct, here's what it looks like when the server doesn't close the client socket:

info: recv: .{ .user_data = 2, .res = 128000, .flags = 4 }
info: recv: .{ .user_data = 2, .res = 95232, .flags = 4 }
info: recv: .{ .user_data = 2, .res = 411136, .flags = 4 }
info: recv: .{ .user_data = 2, .res = 285696, .flags = 4 }
info: recv: .{ .user_data = 2, .res = 128512, .flags = 0 }
info: recv: .{ .user_data = 2, .res = 0, .flags = 0 }

can someone confirm whether

IORING_CQE_F_SOCK_NONEMPTY

has some sort of dependence on TCP segments like FIN?

oh wait, I just checked

test/accept-non-empty.c

, just learned that SOCK_NONEMPTY is also used for accepts to signal that there are more pending connections, neat stuff