You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Peeking at a port that is used after a sleep rarely terminates #9396
use std::comm;use std::rt::io::timer::Timer;fnmain(){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.
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.
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.
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
.
Activity
jdm commentedon Sep 22, 2013
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 commentedon Sep 22, 2013
This is happening because
peeknever yields control to the scheduler, so the sleeping task is starved. It probably should work. I have an unmerged patch that makestask::deschedulework more correctly, a call to which thrown into the loop would make this work reliably.olsonjeffery commentedon Sep 22, 2013
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.life-white.ukwrote:
jdm commentedon Sep 22, 2013
Adding a deschedule call to both my sample and my original code did make it work consistently for me.
alexcrichton commentedon Dec 17, 2013
Closed by #10830, both sends and receives will yield now, and peek no longer exists.
alexcrichton commentedon Dec 17, 2013
On second though, I need to investigate this more to be sure.
Merge rust-lang#9396
Merge rust-lang#9413