Watch channel impl

[OpenTritium]

I've put together a demo of a watch channel that works via atomic replacement, aiming for a completely lock-free design. The main limitation, inherent to this Arc-based lock-free approach, is that it can't provide in-place modifications; every update has to be a clone-and-replace, which is why several of the APIs require a T: Clone bound.

The performance results are really interesting. In a single-threaded environment, it doesn't lag too far behind tokio::watch. And if you look at the raw throughput without considering the async machinery, its read performance in read-heavy scenarios is definitely higher than Tokio's RwLock-based version.

But the real-world story is different. Once you measure the end-to-end performance, including the overhead from the waker system, it's consistently about twice as slow as the native Tokio channel. That performance gap gets even wider as the size of the state T grows, because the clone() cost really starts to hurt.

So, my takeaway is that a robust, RwLock-based implementation is probably the more pragmatic path forward. Still, I think this little "toy" was a meaningful experiment. It could be a great baseline to benchmark an RwLock version against in the future, or maybe it could live on as an alternative watch implementation for specific use cases. What do you all think?

[George-Miao]

Two possible improvements:

• maybe an unsync variant
• use rwlock for performance improvement, as you said.

Overall it looks pretty good.

[OpenTritium]

I've implemented the watch channel based on RwLock. I'm concerned there might be some safety flaws and would appreciate it if more experienced developers could review my code. Thanks!

Link

[George-Miao]

• Why use LSB instead of MSB for disabled? If you just use one MSB then you won't need to worry about steps when increment or decrement. (Ok I do see it's from tokio, which seems like a wired design to me. Maybe we can change that if there's no particular reason for them to do this).
• There are several clippy warnings, which shouldn't be a big problem.
• I still think an unsync version will be a good idea. I can try write an unsync event-listener.

[OpenTritium]

• Using the LSB as a flag eliminates the impact of overflow on the version number. In our pattern, where one side increments the version and the other decrements it, version changes are detected by direct inequality comparison (!=), so we don't have to worry about which one is greater or smaller. For instance, if we take version 0xFFFE and increment it by 2, it will wrap around to 0, but its LSB correctly remains 0. Similarly, if the value were 0xFFFF, incrementing it by 2 would still result in an LSB of 1—it's unaffected by the overflow. By contrast, if we were to use the MSB, an increment like 0x7FFF + 1 would become 0x8000, causing the 'closed' flag bit to be corrupted by the overflow.
• It seems to be because I only had cargo check enabled when using Zed.
• What are the significant benefits that the unsync version would offer?

[George-Miao]

That's the rationale behind having both a sync version and an unsync version - users get to choose which to use based on their use case. It will be too restrictive if we only have single-threaded version, but when we know we can avoid synchronization, we have the choice. I think OnceCell and OnceLock are two great examples.

[OpenTritium]

Yes, for my use case, I definitely need the sync version, so I believe it makes sense to keep this library. What are your thoughts on splitting the tools into two separate crates: one for sync and one for !sync?

[George-Miao]

I don't think that's necessary. Just two mods for two flavors should be enough.

[OpenTritium]

The main issue here is really about how you would separate the features. It actually feels manageable either way, since you can always configure things with features regardless of how it's split. However, I do think that if the sync and !sync versions are going to share a lot of sub-modules, then keeping them merged together is indeed the better approach.

[George-Miao]

Yeah. As I mentioned, once_cell is a good example.

[George-Miao]

Some logistical questions:

• Do you want the crate be placed and maintained in compio-rs org?
• Since it's runtime agnostic, I don't think it's a good idea to be named after compio. We can find a better name for it.

[OpenTritium]

• it's ok
• do you have any idea？

[OpenTritium]

i have fixed these clippy warnning

[Berrysoft]

compio-buf and compio-io are also runtime agnostic.

The smol series crates use async-*, but it might be OK if we also use it.

[George-Miao]

Yea.. we do have async-watch, async-watcher and async-watch2 already, not looking good

[George-Miao]

I just found out that... uh... see is apparently available as a crate name so I squatted it.. what do you think.

[OpenTritium]

To be honest, I feel like watch or observe would have been more intuitive names for this. It always makes me wonder why crates.io doesn't have namespacing like username/crate_name. If this keeps up, people will have to start naming their new crates with emojis or something just to find an available name, haha. Still, I guess there weren't any better choices, and see is actually not a bad name.

[George-Miao]

Lol I did think the same way and actually searched a bunch of words like observe or stare or whatever, but nothing seems to be available, so

[George-Miao]

Let's add the crate to compio-rs first as is, and I can open a PR for the unsync variant later.

[OpenTritium]

i realize there's a significant time diff between us (

[George-Miao]

yea i'm in UTC-4.