DylanZA

since you own the user_data and it is unique for this case, you should not need to worry about extra bits? io_uring will not magically be setting bits without it...

Ah yes. I'm just guessing here, but from your earlier explanation could you have a magic user_data (say 0) for this? you wouldn't need to malloc and it does seem...

I suspect this is going to be an implementation detail, and subject to different states of the ring I wouldnt make any assumptions on the ordering of completions for different...

this is interesting. I believe that should work as the struct order is [hdr][name][control]. Since the buffer as a whole is provided to io_uring in a pool, I think it...

it's difficult to know for sure - but likely this is the overhead of the "wait" part, which is a lot of scheduler and context switching overhead since it has...

> OTOH io_uring_wait_cqes() seems always returns the only CQE regardless on how much of the expected ones was specified in wait_nr argument this is true, but the rest of the...

basically do not wait for both cqes. You want to process each cqe as it happens. in pseudocode: ``` sqe = io_uring_get_sqe(&ring); io_uring_prep_poll_add(sqe, tfd, POLLIN); io_uring_sqe_set_data64(sqe, 0); /* 0 to...

fwiw it looks like GLIBC does this for example on syscalls: https://github.com/bminor/glibc/blob/master/posix/unistd.h#L1091C7-L1091C8 defined here: https://github.com/bminor/glibc/blob/1944817240eeea5c044995e45a771a5a5193ecf1/misc/sys/cdefs.h#L86 I think its a good idea - perhaps @rohanlean can post a patch?

> One way to do that would be to add a 64-byte or a 128-byte CQE & use the extra bytes there for msghdr. This would constrain the msghdr size...