Open Frando opened 7 months ago
I would indeed be neat, but potentially annoying to implement properly. Sadly, I don't currently have the time to implement substantial features like this.
This issue is similar to https://github.com/zesterer/flume/pull/148, where you basically can end up with memory leaks due to the way flume internally works. Not quite the same issue, but memory leaks can't be avoided because there's no shrink_to_fit
in any channel flavor.
I believe the "proper" implementation would be to:
shrink_to_fit
and reserve_exact
methods, among others, oralter_queue(Fn(&mut VecDeque))
/get_queue_mut() -> &mut VecDeque
so that the user is free to do whatever they want, including, but not limited to shrink_to_fit
, reserve_exact
, etc. Although this could potentially cause bugs (?), I don't think it's that bad. I've seen libraries like reqwest use weird fn names to convey the fact that, by using them, they might cause issues or problems (example).Resizing bounded channels might be actually hard to implement because you'd need a way to change how the internal Chan
nel works (its capacity isn't stored in a mutable/atomic integer), but you can probably achieve whatever you're trying to do with wrapped unbounded channels + the stuff I implemented in my PR.
It would be neat if bounded channels could be resized, to increase or decrease the allocated capacity, like
Vec::shrink_to
andVec::reserve_exact
.