On 12/19/2013 12:57 AM, Kevin Ballard wrote:
Running out of memory can certainly be a problem with unbounded channels, but it's not a problem unique to unbounded channels. I'm not sure why it deserves so much extra thought here to the point that we may default to bounded. We don't default to bounded in other potential resource-exhaustion scenarios. For example, ~[T] doesn't default to having a maximum capacity that cannot be exceeded. The only maximum there is the limits of memory. I can write a loop that calls .push() on a ~[T] until I exhaust all my resources, but nobody thinks that's a serious issue.
This is a reasonable question. A channel should be able to handle an indefinitely large amount of traffic over its lifetime. In the absence of performance considerations, there is no reason for its capacity to be more than one. A channel with a capacity of more than one supports pipelining, enabling coarser-grained work units that reduce scheduling overhead. As the capacity grows, that benefit shrinks to zero, while system latency may grow without bound. By contrast, there is nothing inherently time-related about ~[T]. I wonder... maybe filling in the last slot in a channel should also make the sending thread yield, and if the channel is still full when the thread runs again, something interesting is allowed to happen -- by default, nothing or task termination, but you can provide a callback that might grow the channel, or push back upstream, or what-have-you. Then there's only one kind of channel seen by send and recv, maximally optimized, that does whatever fool thing you want, and only ever costs extra at a scheduling boundary when you can afford it. Probably this idea is incompatible with 1:1 threads, or something. Nathan Myers _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
