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: