Skip to content

io_uring: add msg_ring functionality #157

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

rockorager
Copy link
Contributor

io_uring has a function called msg_ring which adds a CQE to a target
ring, which may be operating in a different thread. This can be very
valuable to wakeup a sleeping thread while also giving it data to
operate with.

Zig std doesn't have the prep function from liburing yet, so we emulate
how that function works. Specifically, we are emulating
io_uring_prep_msg_ring_cqe_flags. We are using the *cqe_flags variant so
that we can set a flag on the receiver's CQE. Because of how completion
callbacks work, the same callback will be called twice: once with the
sender's loop and once with the receiver's loop. By setting a flag, we
can distinguish between these. The method allows passing a u32 value
through as extra data, in addition to the pointer. We also pass this
through, but when we detect we are the sender of the message we return a
null. Only the receiver of the message will get the value contained
here.

io_uring has a function called msg_ring which adds a CQE to a target
ring, which may be operating in a different thread. This can be very
valuable to wakeup a sleeping thread while also giving it data to
operate with.

Zig std doesn't have the prep function from liburing yet, so we emulate
how that function works. Specifically, we are emulating
io_uring_prep_msg_ring_cqe_flags. We are using the *cqe_flags variant so
that we can set a flag on the receiver's CQE. Because of how completion
callbacks work, the same callback will be called twice: once with the
sender's loop and once with the receiver's loop. By setting a flag, we
can distinguish between these. The method allows passing a u32 value
through as extra data, in addition to the pointer. We also pass this
through, but when we detect we are the sender of the message we return a
null. Only the receiver of the message will get the value contained
here.
@rockorager
Copy link
Contributor Author

Closing this. This is the wrong approach.

@rockorager rockorager closed this Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant