Help needed improving Kanal

[fereidani]

I open this issue for those kind people who are interested provide help to develop Kanal.

We need help in these areas:

1. Auditing Kanal for UB and security-related issues.
2. Writing tests for all library functions, in all cases. include cases that the function returns an error.
3. Improving documentation

[caass]

Hey, I'm interested in improving documentation. Do you have a general sense of what's needed or should I just check the codebase and start documenting?

[fereidani]

Hey @caass , Thank you, It would be nice.
I think my documentation is insufficient so a general overview would be nice.
Documentation could be in the style of Rust's own MPSC channel to help integrity between Kanal and Rust own documentation.
https://doc.rust-lang.org/src/std/sync/mpsc/mod.rs.html#1-126
Please use wrap_comments = true in your rustfmt.toml with nightly rustfmt.

[Originalimoc]

bounded_async is indeed fast, use bound size 40 with 1500 bytes data in spsc setup gets 23Million pks compare to 4.9M tokio::mpsc. Most gain from no syscall(this includes lock contention). will keep a close eye on unsafe part code.

Edit/Note: 1p2c reduced to 11M from 1p1c 23M, expected bc lock, data integrity passed plus no message loss so far.
Edit2: 1p1c, unbounded_async, only 1.5M, is it expected?

[fereidani]

@Originalimoc unbounded_async should not be much different from bounded 40, it could be related to your software design because in our benchmarks they are pretty close, and sometimes unbounded is faster than bounded.

[Originalimoc]

It's just a dumb two-task tokio async test using unbounded_async, one loop send a bunch one for recv.await, then after all received side calculate count divided by time elapsed, multicore AMD 2 CCD system default tokio runtime.