[Week 2]: crossbeam uring; sink/stream futures; driver access

[lvyuemeng]

Summary

Long Term Development

[Deprecated]

• Continguous memory layout

A unsafe impl in shm ipc suggests:

    pub unsafe fn create(
        fd: BorrowedFd,
        size: usize,
        header: UringHeader<Ext>,
    ) -> Result<NonNull<Self>> {
        // Calculate offsets
        let mut cur = size_of::<Self>();

        let layout_a = Layout::array::<A>(header.size_a()).unwrap();
        let buf_a = align_up(cur, layout_a.align());
        cur = buf_a + layout_a.size();

        let layout_b = Layout::array::<B>(header.size_b()).unwrap();
        let buf_b = align_up(cur, layout_b.align());
        cur = buf_b + layout_b.size();
        ...

A safe uring initiation with continguous memory layout.

• A better Ref api for multiple owner, leave out the space for user to use their own?
  A better lock api for exclusive access in multiple threads, refer lock_api, with a basic implement spin natively.

---

Uring:

• Concurrent data structure for multiple threads.

  • concurrent slab [Deprecated]
  • concurrent queue Reference of lock-free uring.
  • crossbeam lock-free channel.

• Refactor by crossbeam channel with sink/stream asynchronization by futures.

Driver:

• Driver: It's a read-write cache. Current api is deeply related to Runtime, with RunOn to complete the RQE.
  A better suggestion is to integrate above as Submitter and Driver/Receiver for same backend Driver.
  Driver -> Bridge implement Bridge<Submit>/<Receiver>, with submit() or recv_op() to send sqe and receive rqe
  and comtemporarily store it.
  • add lock interface using lock_api.
  • asynchronize by futures.