-
Notifications
You must be signed in to change notification settings - Fork 816
Allow dynamic modification of io-threads num #2033
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
base: unstable
Are you sure you want to change the base?
Conversation
UTs pending atm. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## unstable #2033 +/- ##
============================================
+ Coverage 71.02% 71.37% +0.34%
============================================
Files 122 122
Lines 66171 66050 -121
============================================
+ Hits 46999 47142 +143
+ Misses 19172 18908 -264
🚀 New features to boost your workflow:
|
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.
Nice. Just minor things, looking forward to the tests.
Hey @uriyage, just curious , can you please explain the safety concerns a bit more i.e. why we would want to drain all jobs and inactivate all threads instead of the min num required? |
451df91
to
cde1b5a
Compare
@ayush933 I don't recall the exact workflow, but I remember attempting something similar, and it affected the logic of dynamically adjusting the threads or the client |
40b1d3f
to
c450698
Compare
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.
Just some nits, but still would like @uriyage to take sign off as well, he knows more about this code.
LGTM. I left one small comment about the log verbosity |
500689b
to
5698821
Compare
Signed-off-by: Ayush Sharma <mrayushs933@gmail.com>
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.
Conceptually approve. I didn't review the code (just looked briefly).
Bug fix where calling
pthread_join()
from main thread for an IO thread would hang indefinitely
What is the severity of this bug? Which scenario triggers it, from a user's perspective? Do we need to backport the bugfix? (If we need that, may need to split out the bugfix to a separate commit that we can backport, since this PRs is a new feature + a bugfix. We should not backport the new feature.)
Before this feature, the only time we called |
Currently, it is only used by |
Item from #761
This PR has the following changes
pthread_join()
from main thread for an IO thread would hang indefinitely. This is becauseIOThreadMain()
doesn't have a cancellation point.Sopthread_cancel()
from main thread is not honored.Can be reproed by calling
shutdownIOThread()
from the main thread for any active thread with empty job queue.Fixed by adding cancellation point in
IOThreadMain()
.io-threads
config runtime modifiable.