Peeking at a port that is used after a sleep rarely terminates

[jdm]

use std::comm;
use std::rt::io::timer::Timer;

fn main() {
    let (port, chan) = comm::stream();
    do spawn {
        let mut timer = Timer::new().unwrap();
        timer.sleep(10);
        chan.send(());
    }
    loop {
        if port.peek() {
            break;
        }
    }
    port.recv();
}

This will often never leave the loop. If the timer is removed, it always succeeds instantly. If the peek is removed (so we block on receiving), it always succeeds once the sleep terminates.

[jdm]

In addition, if I add error! statements after the sleep call, I don't see any output when the program doesn't terminate. Whether that means that the output is buffered or the timer simply doesn't wake up, I don't know.

[brson]

This is happening because peek never yields control to the scheduler, so the sleeping task is starved. It probably should work. I have an unmerged patch that makes task::deschedule work more correctly, a call to which thrown into the loop would make this work reliably.

[olsonjeffery]

I can kinda sorta verify this on OSX mountain lion.

The provided code sample works, as is.. but if I increase the timeout to
over 100 msecs (to include 101), then it hangs..

based on my println!()-based debugging.. it seemed like it was hanging on
waking up from the sleep..

On Sat, Sep 21, 2013 at 5:16 PM, Josh Matthews notifications@github.comwrote:

use std::comm;use std::rt::io::timer::Timer;
fn main() {
let (port, chan) = comm::stream();
do spawn {
let mut timer = Timer::new().unwrap();
timer.sleep(10);
chan.send(());
}
loop {
if port.peek() {
break;
}
}
port.recv();}

This will often never leave the loop. If the timer is removed, it always
succeeds instantly. If the peek is removed (so we block on receiving), it
always succeeds once the sleep terminates.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9396
.

[jdm]

Adding a deschedule call to both my sample and my original code did make it work consistently for me.

[alexcrichton]

Closed by #10830, both sends and receives will yield now, and peek no longer exists.

[alexcrichton]

On second though, I need to investigate this more to be sure.