Skip to content

pipes::peek returns true unexpectedly #3905

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
brson opened this issue Nov 2, 2012 · 1 comment
Closed

pipes::peek returns true unexpectedly #3905

brson opened this issue Nov 2, 2012 · 1 comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Nov 2, 2012

extern mod std;
use core::pipes::*;
use std::comm::DuplexStream;
use core::task;

fn main () {
    let (chan, port): (Chan<int>, Port<int>) = stream();

    do task::spawn() |move port| {
        assert port.recv() == 123;
        assert !port.peek();
    }

    chan.send(123);
}

There is no message available but peek returns true, likely because this: https://github.com/mozilla/rust/blob/incoming/src/libcore/pipes.rs#L516

I expect that anytime peek returns true I can call recv successfully.

@brson brson closed this as completed in b62844e Nov 2, 2012
@eholk
Copy link
Contributor

eholk commented Nov 23, 2012

Wow, I should pay more attention to these threads :)

The original behavior (closed pipes return true) was intentional on my part. The rational is that peek returns true when something has happened on the pipe that you might care about. For example, if we had a loop that kept using peek to test for a message, we'd want to know if the pipe closed so we could terminate the loop.

That said, I can see the argument for the new behavior, so I'm fine if people would rather it be the other way. Perhaps we could have peek that returns an enum of MessageWaiting, Terminated or NoData.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

2 participants