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

Question: Fairness when multiple receivers are doing work-stealing #128

Closed
GermanCoding opened this issue Aug 2, 2023 · 2 comments
Closed

Comments

@GermanCoding
Copy link

So, I have the following use case:

I have multiple async workers (futures) that all want to process data (send over a network connection in this case).

I want to use flume to let them all receive the same set of messages, where flume picks a receiver which then performs the sending over the network.

What I'm wondering is, how fair is the load distributed across multiple receivers? In my case, when the receiver has processed data, the task isn't actually completed yet: Network data is still in-flight and needs to be processed by the other side. Yet the receiver is already capable of taking in new messages and hence will call recv() again. In this case, I want the other receivers to do work next, before the previous receiver gets new work. This would ensure equal load on all network connections.

Therefore, my question is: Does flume distribute fairly? If a receiver gets a message and then calls recv() again, can it get new work before another receiver, which has been blocked on recv() the entire time, got its share of data?

@zesterer
Copy link
Owner

zesterer commented Aug 2, 2023

The current implementation of flume has receivers make claims on the queue, so starvation/unfairness should not occur. Threads will be woken to receive items in the approximate order that they called .recv().

@GermanCoding
Copy link
Author

Sounds good, that's exactly what I'm looking for! Thanks

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

2 participants