Restioson
Allocate queues in channel according to capacity
In case the user passes a capacity, we know how many elements we will be storing in those queues. We can initialise them directly with this capacity which avoids growing those buffers on demand.
Hm, I would actually tend to disagree with this change. This adds a fixed cost of 8 * capacity bytes per each type of mailbox, even if you don't use them. I intentionally left them as Vec::new as that doesn't allocate until use.
Hm, I would actually tend to disagree with this change. This adds a fixed cost of
8 * capacitybytes per each type of mailbox, even if you don't use them. I intentionally left them as Vec::new as that doesn't allocate until use.
On the other hand, with this change we'd have a much more predictable memory footprint as it wouldn't change during operation.
I am not sure what is better?
If a user really operates on constrained hardware or wants to preserve memory, they could set capacity to 0 right?
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 works! Seems like an important enough case to cover.
If they set capacity to zero that'd affect the default priority queue too, though
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 SendFuture will yield until the actor is ready to process the message.
But other than that, send will block the current task until the message is processed, same as before.
Am I missing something?
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 zero-cost abstractions and pay-for-what-you-use, I'd like the extra channels to add as little overhead as possible if you don't use them.
It's also worth mentioning that the ordering behaviour might not work as expected with a rendezvous channel, but I'm not 100% sure of this
Ideally, the user shouldn't have to choose between getting to use
split_receiverand not allocating extra capacity for a channel that is never used. In the spirit of Rust's zero-cost abstractions and pay-for-what-you-use, I'd like the extra channels to add as little overhead as possible if you don't use them.
Hmm, I see where you are going with this. I think one could still argue that users should know whether they are using split_receiver and will thus pay the memory cost anyway so it doesn't matter whether they pay it on startup or during runtime.