unsafe impl Send+Sync for Submitter, SubmissionQueue, CompletionQueue#283
unsafe impl Send+Sync for Submitter, SubmissionQueue, CompletionQueue#283problame wants to merge 1 commit intotokio-rs:masterfrom
Send+Sync for Submitter, SubmissionQueue, CompletionQueue#283Conversation
…onQueue` The `IoUring` type already has `Send` + `Sync` impls. In [tokio-epoll-uring](https://github.com/neondatabase/tokio-epoll-uring), we use `split()` and need the `Submitter`, `SubmissionQueue` and `CompletionQueue` to be `Send` (not sync, though). This PR adds those `unsafe impl`s, and adds hopefully not too repetitive commentary on why these impls are safe. --------- Co-authored-by: Conrad Ludgate <conrad@neon.tech> Cherry picked from commit neondatabase/fork--tokio-rs--io-uring#bbc5a0c5f6cde9051037ec2fcc648cbadb7a80b4
|
You seem to have to use unsafe to get |
|
Sorry, I'm not following. Who's talking about
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 |
|
This would be useful in my project as well |
|
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 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 So for this scenario it's useful to have non-Send |
The
IoUringtype already hasSend+Syncimpls.In tokio-epoll-uring, we use
split()and need theSubmitter,SubmissionQueueandCompletionQueueto beSend(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 conrad@neon.tech
Cherry picked from commit neondatabase@bbc5a0c