Ecosystem: Make !Sync Great Again!

[OpenTritium]

I've noticed that one of compio's most competitive advantages lies in single-threaded scenarios. However, because the Rust async ecosystem has long been dominated by Tokio, nearly all asynchronous data structures and primitives are Sync. We could implement higher-performance, non-Sync versions of these as alternative options specifically for single-threaded use cases. What does everyone think of this idea?

[Berrysoft]

Thank you. But !Sync has never been great, let alone great again. Furthermore, I don't want to be shot at my ears:)

Would you provide a list of data structures that you would like to be !Sync?

[OpenTritium]

First, it must be a "delay queue" (because I really need one right now). I'm currently researching the timer modules of Tokio and Compio (I'd really like to upgrade current implementation, but studying them seems to be taking some time and brain cells). To achieve a high-performance delay queue, it seems it must be tightly coupled. If it's not coupled, the only option is to spawn a task for wakeup. Which approach do you think is better?

[Paraworker]

Sounds good, but some data structures still need a Send variant to allow communication between runtimes running on different threads, for example channels. Perhaps provide both a LocalChannel and a SyncChannel?

[OpenTritium]

yep, we've talked about this actually.

[OpenTritium]

I've written another small utility, under 100 lines of code. It's a debouncer implemented using a sleep function. I feel it's a bit crude, but its main advantage is its simplicity. Really, the only API that's coupled to a specific runtime is sleep. In other words, it could be made to run on any runtime if you could provide a function pointer to an async sleep implementation. I'm just not sure if I should go down that route, though.

[OpenTritium]

and it's unsync