Efficient single-threaded client implementation?

[SUPERCILEX]

I'm looking to build a clipboard manager with a single threaded event loop that uses io_uring. AFAIK I should be able to add the wayland socket as one of the tasks my event loop is waiting for. What's the best way to integrate with this crate without going through a bunch of Arcs and Mutexes? I'm aware of connection_fd which will at least let me be single-threaded with io_uring, but it just seems like a waste to have a bunch of overhead for multi-threading if I'm not going to use it.

[ids1024]

This is one thing that seems awkward to do with Rust currently. There isn't a good way to define types that are generic over whether they use Arc/Mutex or Rc/RefCell, and such.

just seems like a waste to have a bunch of overhead

You're not wrong that it adds overhead, but "a bunch" is likely an overestimate. I believe Mutex shouldn't have fairly little overhead without lock contention (and there shouldn't be any in your single-threaded use). I don't have any numbers, but I'd expect little measurable impact.

Though if you come up with a good way to benchmark this, it probably isn't too hard to find-and-replace the uses of Arc/Mutex to use Rc/RefCell and see how the performance compares.

[SUPERCILEX]

You're not wrong that it adds overhead, but "a bunch" is likely an overestimate. I believe Mutex shouldn't have fairly little overhead without lock contention (and there shouldn't be any in your single-threaded use). I don't have any numbers, but I'd expect little measurable impact.

I absolutely agree with this: in the grand scheme of things it's highly likely to be irrelevant. However, that's similar to leaving the water running while brushing your teeth—does it really matter? Nah, but it still feels wrong.

Anyway, I think this a "would be nice someday" issue. Hopefully I'll have time to look into it in a few months.

[ids1024]

Perhaps more important than the use of Arc and Mutex is the Send + Sync bound wayland-rs requests for udata.

That forces the caller to either also use thread safe types, or use some unsafe impl hack. Which may be problematic in some cases.

Not sure there's any easy way to improve that though. Maybe you'd need some kind of split between the type of QueueHandle for thread-safe and singled-threaded event queues...