and cast the user_data from cqueue::Entry to ptr to context via
fn user_data(&self) -> u64
Here is a use case where we find a need to access previously application-supplied user_data of squeue::Entry:
io_uring completes submitted SQEs out of order unless they are linked and within the same submit call. When O_Direct is used, alignment-write must be taken into account. Two writes/SQEs to the same page cannot be submitted concurrently into SQ due to out-of-order execution and completion. That is, the second write should wait until the prior in-progress SQE is reaped.
Theoretically, there may be more than two concurrent writes to the same page. We only need to submit the last one and drop others and free their associated resources through context. We indeed may design structs to save the original ptr to achieve this goal, but it would be great if we can access user_data of squeue::Entry and re-use the reaping cqueue::Entry handling code.
It is true that the current API works perfectly well in most cases: bind pointer to context to squeue::Entry through
and cast the user_data from cqueue::Entry to ptr to context via
Here is a use case where we find a need to access previously application-supplied user_data of squeue::Entry:
io_uring completes submitted SQEs out of order unless they are linked and within the same submit call. When O_Direct is used, alignment-write must be taken into account. Two writes/SQEs to the same page cannot be submitted concurrently into SQ due to out-of-order execution and completion. That is, the second write should wait until the prior in-progress SQE is reaped.
Theoretically, there may be more than two concurrent writes to the same page. We only need to submit the last one and drop others and free their associated resources through context. We indeed may design structs to save the original ptr to achieve this goal, but it would be great if we can access user_data of squeue::Entry and re-use the reaping cqueue::Entry handling code.