Open cramertj opened 5 years ago
I tested it locally but could not reproduce it (Windows and Linux(WSL-Ubuntu)). As far as I look at history (pr and master), this problem seems not to occur in Linux, so I think this is an issue specific to macOS or a Travis issue.
Recent Travis's macOS build is very unstable regardless of this test (https://github.com/rust-lang-nursery/futures-rs/pull/1787#issuecomment-519628394), so for now, I'm guessing this is a Travis issue.
(The OS looks irrelevant, but I have never been able to reproduce it locally.)
I've been reproducing this on linux in futures 0.1.29
, the problem is its very ephemeral and prone to randomly working 99% of the time.
I can't make it do this on nightly rust, but I can do it on current stable rust.
Attaching gdb once it deadlocks gives me:
gdb thread apply all bt full
Hopefully something in that mess is relevant.
This issue happens to be easily reproducible on my system. The deadlocked situation is as follows:
let o9 = rx3.recv().unwrap();
. Waits for T3 to send a sender through tx3
/ rx3
.block_on_stream(rx.buffer_unordered(N))
. It has obtained 8 receivers from rx
already; 4 of them have been used, other 4 are buffered and pending. Waits for T1 to send items through any of 4 receivers. Note that T2 isn't polling from rx
at this point. block_on(tx.send(myrx)).unwrap();
. In fact it has already sent all 9 items through tx
, but is blocked while flushing the sink, waiting for free capacity in the channel.The T3 should be able to proceed successfully, since channel has capacity 1 and additional 1 for the sender. Unfortunatelly the implementation of per sender capacity is racy and it is possible for a sender to be incorrectly parked even though free capacity is there. If the receiver is being polled from, the situation eventually corrects itself. But in the case here rx
is not being polled from so the problem persist.
Execution that leads to a mpsc bounded sender being incorrectly parked:
parked_queue
The receiver is woken up afterwards, but it isn't being polled from so that doesn't help.
seen on this change: https://github.com/rust-lang-nursery/futures-rs/pull/1789 in this job: https://travis-ci.com/rust-lang-nursery/futures-rs/jobs/224053387