-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding remaining()
and capacity()
methods to Sender
and Receiver
#71
Comments
remaining()
and capacity()
methods to Sender and Receiver
remaining()
and capacity()
methods to Sender and Receiverremaining()
and capacity()
methods to Sender
and Receiver
Yes, I believe it should be possible to add these methods by just forwarding them from the |
…` and `Receiver` (hawkw#71)
Just wanted to give this a quick bump - the PR looks to be in decent shape. If there is anything I can do to help get it merged, let me know - as it would be very useful for one of my projects! |
@kiranshila so I think the only real blocker is that there's some weird behavior around the len() method that merging this PR would expose -- I think when dropping the channel. See the failing doc tests in the PR. Eliza was going to look into it, and I was also going to try to look into it..I haven't had the time and I suspect the same for Eliza. |
Currently, there is no way to get the total capacity, remaining capacity, or used length of a MPSC channel. This PR adds the following methods to `mps::Sender`, `mpsc::Receiver`, `mpsc::StaticSender`, `mpsc::StaticReceiver`, and their `mpsc::blocking` equivalents: - `capacity`: Returns the total capacity of a channel, including used capacity. - `len`: Returns the number of messages currently in a channel. - `remaining`: Returns the current _free_ capacity of a channel (`capacity - len`). - `is_empty`: Returns `true` if there are no messages in a channel. Additionally, I've fixed a bug in `Core::len` where, if the channel is closed and contains zero messages, the length returned is equal to its capacity rather than 0. This is due to the `Core::len` function incorrectly testing whether `head == tail` without masking out the `closed` bit, which may be set in either `head` or `tail` when a channel closes. This causes us to believe a closed channel is full when it's actually empty. I've added tests reproducing this. Fixes #71 --------- Co-authored-by: Joel Crevier <jcrevier@dragos.com> Co-authored-by: Eliza Weisman <eliza@elizas.website>
Glad to see this merged 😄 🎉 |
## v0.1.5 (2024-04-06) #### Features * **mpsc:** add `len`, `capacity`, and `remaining` methods to mpsc (#72) ([00213c1](00213c1), closes [#71](#71)) #### Bug Fixes * unused import with `alloc` enabled ([ac1eafc](ac1eafc)) * skip slots with active reading `Ref`s in `push_ref` (#81) ([a72a286](a72a286), closes [#83](#83), [#80](#80))
Hello! This crate is very neat. It would be very helpful for metrics if
mpsc::Sender
andmpsc::Receiver
channel handles exposed a way to determine the capacity and remaining slots. TheThingBuf
queue has aremaining()
and acapacity()
method, so it seems odd that Sender or Receiver don't. I'm open to writing up a PR to add this, but I noticed that the implementation of Sender and Receiver was a bit different thanThingBuf
-- is there any reason these weren't exposed? From a quick glance it seems like they would be easy to add toSender
andReceiver
by just using thelen()
andcapacity()
methods fromself.inner.core.core
The text was updated successfully, but these errors were encountered: