-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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 to main loop timeout calculation leading to a tight loop for a max period of 1 ms #4671
Conversation
1315712
to
37b4ef4
Compare
ba3ee8d
to
f405243
Compare
37b4ef4
to
f5ffbf8
Compare
f405243
to
4dd41b7
Compare
f5ffbf8
to
7403c10
Compare
rd_kafka_q_serve(rk->rk_ops, (int)(sleeptime / 1000), 0, | ||
/* Use ceiling division to avoid calling serve with a 0 ms | ||
* timeout in a tight loop until 1 ms has passed. */ | ||
int timeout_ms = (sleeptime + 999) / 1000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had one concern with the overflow but that will never happen as we use CLOCK_MONOTONIC
and hence will never reach the limit for rd_ts_t
.
* Fix to main loop timeout calculation leading to a tight loop for a | ||
max period of 1 ms (#4671). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use something easier to understand than tight loop
. The later statement is more comprehendible than this.
leading to a tight loop for a max period of 1 ms When the main thread loop was awakened less than 1 ms before the expiration of a timeout, it was serving with a zero timeout, leading to increased CPU usage until the timeout was reached. Happening since 1.x
2b56329
to
6a8f931
Compare
leading to a tight loop for a max period of 1 ms When the main thread loop was awakened less than 1 ms before the expiration of a timeout, it was serving with a zero timeout, leading to increased CPU usage until the timeout was reached. Happening since 1.x
When the main thread loop was awakened less than 1 ms before the expiration of a timeout, it was serving with a zero timeout, leading to increased CPU usage until the timeout was reached. Happening since 1.x