Skip to content
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

How is order determined when priorities match? #75

Open
matanmarkind opened this issue Oct 30, 2023 · 2 comments
Open

How is order determined when priorities match? #75

matanmarkind opened this issue Oct 30, 2023 · 2 comments

Comments

@matanmarkind
Copy link

If multiple items are sent to the channel with the same priority, is there any promise about the order they will be received? In particular I want to know if sending order will be preserved.

So if I do the following:

channel.send(Item { priority: 1, val: X });
channel.send(Item { priority: 1, val: Y });

Is there any guarantee that X will be received before Y?

@rmcgibbo
Copy link
Owner

The internal data structure is a BinaryHeap, so the current behavior probably depends on that. But there's no guarantee.

@cameroncros
Copy link

This is a pretty major break in the definition of a "channel", and should be highlighted in your documentation.

All data sent on the Sender will become available on the Receiver in the same order as it was sent

https://doc.rust-lang.org/stable/std/sync/mpsc/fn.channel.html

The current impl definitely does not guarentee order:

use async_priority_channel::unbounded;

#[tokio::main]
async fn main() {
    let (tx, rx) = unbounded();

    for i in 0..10 {
        tx.send(i, 0).await.unwrap();
    }

    loop {
        let i = rx.recv().await.unwrap();
        println!("Got: [{i:?}]");
    }
}

Results in:

Got: [(0, 0)]
Got: [(2, 0)]
Got: [(6, 0)]
Got: [(9, 0)]
Got: [(8, 0)]
Got: [(5, 0)]
Got: [(7, 0)]
Got: [(4, 0)]
Got: [(1, 0)]
Got: [(3, 0)]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants