On Tue, Dec 24, 2013 at 10:33 PM, Patrick Walton <pcwal...@mozilla.com> wrote: > On 12/24/13 7:23 PM, Daniel Micay wrote: >> >> I think the ability to deadlock is overstated... as it's not going to >> happen without two-way communication. If you have clear consumers and >> producers then it's not an issue you can hit. If you don't, then you >> can still have a well-defined communication protocol handling the >> issue. > > It can happen with one-way communication too. Here's the example I always > give. Suppose you have an photo app that fetches a list of images from the > network, sorts them by date, and places the result into a folder. You might > structure it as two tasks, A and B, and two channels, "Images" and "Done". A > fetches images one by one and places them into the "Images" channel. When > it's done it sends a ping on the "Done" channel. B waits on the "Done" > channel, then drains the "Images" channel, sorts the results, and writes the > result into a folder.
Ah, I was thinking about simple thread pools and task trees with a single work queue and didn't consider more complex situations like this. > Despite having only one-way communication, this app contains a nasty > deadlock hazard with bounded channels. If there are more images than the > size of the "Images" channel then you will deadlock. Your unit tests may not > catch this, because it only happens if you have a lot of images. Unbounded > channels do not have this problem. In an example where it's not totally serialized, the bounded queue would handle the source being a fast solid state disk and the destination being a slow hard drive but the unbounded queue will deplete all the available memory with enough images. Your unit tests probably aren't going to catch either issue. The unbounded queue still has a bound, it's just higher. There's a greater chance of hitting the limit on a bounded queue since it's probably lower, so it will happen more in production *and* in the tests. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
