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

Clarification on the nature of "starving" #18

Open
dylanede opened this issue Aug 21, 2017 · 2 comments
Open

Clarification on the nature of "starving" #18

dylanede opened this issue Aug 21, 2017 · 2 comments

Comments

@dylanede
Copy link

The examples mention that unsubscribing from certain streams is necessary in order to stop other streams from "starving". It would be helpful if the documentation could explain what the conditions that lead to starvation are, as there doesn't appear to be any other mention of it.

@unrealhoang
Copy link

unrealhoang commented Aug 29, 2017

As I understand, in the current API:

let (send, recv) = multiqueue::broadcast_queue(4);
for i in 0..2 { // or n
    let cur_recv = recv.add_stream();
    thread::spawn(move || {
        for val in cur_recv {
            println!("Stream {} got {}", i, val);
        }
    });
}

The recv itself is a stream - a reader with cursor into the queue (each cur_recv in the loop is also an another stream), so if recv not moving its cursor (by reading/iterating), the queue will not accept more message if it is already at its limit, thus, prevent producer from producing.

And @schets addressed this API problem in this: #15

@schets
Copy link
Owner

schets commented Oct 25, 2017

The issue is caused since multiqueue currently stalls the producer when a consumer is behind. I'm looking into an api that allows consumers to remain unmonitored by the producer and error when they are overwritten. I'll update the docs with a good example when I have some time

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