Thomas Eizinger
Thomas Eizinger
> If a user really operates on constrained hardware or wants to preserve memory, they could set capacity to 0 right? I want to add a test that this actually...
> If they set capacity to zero that'd affect the default priority queue too, though And? It effectively means that `split_receiver` is useless because you can't queue the message so...
> Ideally, the user shouldn't have to choose between getting to use `split_receiver` and not allocating extra capacity for a channel that is never used. In the spirit of Rust's...
> This sounds perfect for a crate to be re-exported by an extension crate! Might have some overlap with [spaad](https://github.com/Restioson/spaad) An alternative could be to: - Move current code from...
Do we want this for 0.6?
Why is u32 not good enough? Are you thinking of custom priorities with enums? A potential downside of more type parameters might be increased compile-times, plus such a type may...
> > Why is u32 not good enough? Are you thinking of custom priorities with enums? > > Yes, this is what I was thinking. It might be a bit...
An advantage of a fixed set of priorities would be that we can guarantee FIFO across a single priority because we can implement it by just having one queue per...
> That's true. I mostly worry about the flexibility concerns here. Yeah I can see that. Given how much it could simplify internally, what do you think of trimming the...
In case https://github.com/Restioson/xtra/pull/133 lands, we can rename the constructor and have `Mailbox::bounded` and `Mailbox::unbounded` which should certainly fix this.