Entry getters and setters

[sugarraysam]

Adding a few convenience functions.

(1) set_user_data is useful for SQ push retries. Most applications working with iouring use a Slab or other indexed storage to bridge between SQ ring and CQ ring. If you retry, you have to re-index stuff, thus mutating the user_data becomes really convenient (see: https://gist.github.com/sugarraysam/01008d85a418aa71a5aac04ce2a1a623)

(2) clear_flags is convenience as well. API only allows "augmenting" the flags with |= so at least now we can reset.

(3) get_opcode this was hidden and is good to see if you get an opaque Entry.

[quininer]

This is actually different from my initial design. Entry should be constructed at the end, and users should not store it. Do you have a use case?

[sugarraysam]

This is actually different from my initial design. Entry should be constructed at the end, and users should not store it. Do you have a use case?

Interesting. My use case is I build futures which are state-machine to drive iouring completions. So the basic workflow is something like this:

enum State {
    Unsubmitted { entry: Entry }
    Submitted { idx: usize }
    Completed
}

And the state machine transitions from Unsubmitted -> Submitted -> Completed

The thing is in the unsubmitted state, you must support retries for robustness, that means being able to clone entries, and reset user_data field (because we use an index storage to bridge between sqe/cqe, and represent "pending IO").

So in that use case, the entry is stored and owned by the future itself, until we have successfully committed. We take advantage that Entry: Clone to enable retries.

When do we retry?
-> ring full caused by temporary ops spike

[sugarraysam]

But more importantly, forget the previous comment, Entry is super useful because it is type erased, so you can store any opcode seamlessly.

[quininer]

This makes sense.