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.
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.
You could argue that this is bad design, and of course it is bad design if you have bounded channels, but one of the purposes of API design is to minimize the fallout of ill-thought-through designs.
Patrick _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
