Add Sender::len to mpsc channel

[barafael]

I'm usually choosing channel sizes intuitively. I frequently miss having empirical data on how full the channels in my system are during normal operation or more exotic load situations.

I'd like to either have public functions on the mpsc::Sender that allow me to see how many elements are in there, like crossbeam::channel::Sender::len.

It would also be fine to emit the channel length as a metric of sorts, like attempted in this PR.

[Darksonn]

Adding a Sender::len method seems reasonable enough. More complex solutions with tracing would need more details on exactly what is being proposed.

[barafael]

The Sender::len would be completely sufficient for me, it seems like a worthwhile API addition. Should also be available on WeakSender probably. I'll take a shot at it, would you mind pointing me in a direction?

[Darksonn]

You should probably add a method here, and use it to provide a len method on the Rx/Tx types in chan.rs. Then you can add methods on the user-facing channel types that call these methods.

[barafael]

Actually, I think simply tx.max_capacity() - tx.capacity() does exactly what I need. I'm not sure this warrants an extra method?

[Darksonn]

Hmm, there's no equivalent to that for the unbounded channel, so I am still okay with adding a len method.

[dan-da]

I don't understand why this issue was closed since it explicitly requests a len() method on mpsc::Sender and references crossbeam::channel::Sender::len(). The merged PR #6348 adds methods to the receiver not the sender.

The lack of a sender len method is presently causing me difficulties as I attempt to migrate from another crates's channel impl. I was hoping to remove a dep, but may not be able to until this is implemented.

request reopen.

[Darksonn]

I suppose that is fair enough. That said, it's probably somewhat tricky to implement. You need information from fields that are currently only accessible to the receiver.