unsafe impl Send+Sync for Submitter, SubmissionQueue, CompletionQueue

[problame]

The IoUring type already has Send + Sync impls.

In tokio-epoll-uring, we use split() and need the Submitter, SubmissionQueue and CompletionQueue to be Send (not sync, though).

This PR adds those unsafe impls, and adds hopefully not too repetitive commentary on why these impls are safe.

---

Co-authored-by: Conrad Ludgate [email protected]
Cherry picked from commit neondatabase@bbc5a0c

[quininer]

You seem to have to use unsafe to get &'static mut or use scope thread to make sense. I would recommend submission_shared and completion_shared.

see https://github.com/tokio-rs/io-uring/pull/100/files#diff-3a884378bde161d43e3099c530c5090847e826cb4501d4f7a803144e6bde14d3

[problame]

Sorry, I'm not following. Who's talking about &'static mut ?

I would recommend submission_shared and completion_shared.

The unsafe impls proposed in this PR allow movement of Submitter, SubmissionQueue, and CompletionQueue, to different threads in consuming code, without any unsafe.

I consider that strictly better than the unsafe fn submission_shared() and unsafe fn completion_shared().

[Nehliin]

This would be useful in my project as well

[DXist]

I think there is no one size fits all approach. Maybe a solution could be to enable Send via feature.

I'm personally biased towards the ring-per-thread setup recommended by the io_uring author. With non Send IoUring and Submitter interfaces it's possible to provide push_shared method since only one thread is allowed to enqueue io.

I prefer to queue all io operations and submit then in batches. During submission I might do random lookups in large in memory indices and expect frequent cache misses.

To hide cache miss latencies I could issue software prefetch instructions, do yield and interleave application logic using several coroutines.

Each coroutine could accept shared reference to IO driver that holds IoUring instance on Linux platforms. To allow each coroutine to submit new io operations there should be a push-like method that takes shared reference to thread-exclusive Submitter instance.

So for this scenario it's useful to have non-Send IoUring and push functionality via shared reference to a single non-Send Submitter.