Possible deadlock footgun with lost consumer

[vorner]

I noticed the send on the sender no longer returns a result. I find this a little bit troubling. Consider the producer-consumer design pattern. Originally, the producer would be doing something like sender.send(stuff).unwrap().

Now, if the consumer terminated due to an error (for example by panicking), the panic would propagate, or would require the producer to handle it somehow. The application would probably terminate by an error. However, in the current implementation, the producer will deadlock (in case of bounded channel, in case of unbounded, it'll just keep eating memory forever), not bringing attention to the problem automatically by eg. crashing.

The previous version was a little bit more typing, but seemed to prevent these kinds of subtle bugs.

[ghost]

This aspect of the new design is unfortunate, but intentional. It was a really difficult decision to make. See #39 for the discussion and rationale.

The good news is that it's still possible to simulate the old interface:
https://github.com/crossbeam-rs/crossbeam-channel/blob/master/examples/mpsc.rs

[vorner]

Oh, I see there's some point in the unidirectionality and why bidirectional closing can be a footgun too.

Anyway, two things:

• Someone in the thread mentioned that if a deadlock is possible to detect (I'm not sure if it is possible), it would still make sense to panic from within the .send. I only skimmed the text, but I think nobody reacted to that one. Even opportunistic detection of a bug could be helpful (and deadlocking is hardly a desired behaviour).
• It would be nice to actually mention the case with no receivers in the documentation ‒ maybe it looks silly, but I actually had to write some code to see if it would start throwing the items out or deadlock.

[ghost]

Regarding deadlocks, are you suggesting to panic in situations like the following?

• Sending into a full channel without receivers.
• Receiving the second message from channel::after (one message is delivered only and the channel is never closed).
• Selecting over no operations (currently this just blocks forever).
• Selecting over operations that will never complete.

[vorner]

Yes, something like that… but being careful about it. I mean, trying to receive the second one on after will definitely deadlock, but if it's part of select, something else might succeed, so it is not necessarily a bug and can probably happen as a corner case of something.