I have application that receives some packets from network and put them to bounded but very large crossbeam channel. There are many tasks putting into the same channel using only try_send and one thread reading it using try_recv. Tokio runtime has 6 threads. I'm using crossbeam 0.5.15 and rust toolchain 1.86.
What I don't understand: profiler tells me that 7% of try_send time I spend on Mutex here: crossbeam/crossbeam-channel/src/waker.rs at 983d56b6007ca4c22b56a665a7785f40f55c2a53 · crossbeam-rs/crossbeam · GitHub

This is something I haven't expected -- I thought that if receiver is using try_recv Walker is always empty and I struggle to understand when it is not.

I've tried to simulate this problem in small application, but it doesn't catch the problem. Any ideas in what situation crossbeam channel with try_send/try_recv needs to notify?

1 post - 1 participant

Read full topic