-
Notifications
You must be signed in to change notification settings - Fork 207
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
fix: threads can skip the line in publisher flow controller #422
Conversation
This allows to hold the queue of threads and their reservation data in a single structure, no need for the separate deque and reservations dict.
The solution looks good, but I worry about the increase in complexity. Do you think the risk of starvation is high enough to warrant this change? |
I'd say yes, here's my thinking:
An argument against could be that users will not even be publishing messages in multiple threads using a shared client instance, most of them will probably just publish them in a single thread in a tight loop. But since we decided back then to make the flow controller thread-safe, then let's also keep it robust, which requires some inherent complexity anyway. |
Okay, fwiw I agree with you that it's best to prevent hard-to-debug issues now. I wish there was a standard flow control mechanism we could just pull off the shelf, because there's some subtlety in this class. |
Fixes #421.
Contrary to the bytes reservations, free message slots are not distributed in FIFO order among the waiting threads, meaning that a message arriving later could be accepted before a message already waiting in the queue.
This PR fixes it by enforcing FIFO distribution of available message slots + some simplifications of the logic and data structures.
Tip: Might be easier to review commit-by-commit, each contains a well-rounded change to the codebase.
PR checklist: