-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
MDEV-34129 mariadb-install-db appears to hang on macOS #3253
base: 10.5
Are you sure you want to change the base?
Conversation
|
A bug in signal_handler thread initialization led to an overcomplicated implementation of wait_for_signal_handler_to_end, namely that we could fail to initialize the signal handler but mark it as active anyway. This meant that we could wait for it to terminate when it didn't exist in the first place. Additionally, let's immediately close down the signal handler loop when we decide to break connections--it's the start of process termination anyway, and there's no need to wait once we've invoked break_connections.
60e2be0
to
45279cb
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.
I don't understand the fix. What do you mean by "we could fail to initialize the signal handler but mark it as active anyway"? How could it have happened?
static void wait_for_signal_thread_to_end() | ||
{ | ||
uint i, n_waits= DBUG_EVALUATE("force_sighup_processing_timeout", 5, 100); |
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.
you removed "force_sighup_processing_timeout", but it's used in the test
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 removed that part of the test, too, because as far as I can see it wasn't necessary; it was only needed because we had to wait, but we had to wait because of the bug that was in the signal_hand
function.
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 should add that by using pthread_join
, we'll wait for all SIGHUP
processing to finish, so there's no need for a special timeout. Joining pthreads is considered a best practice for the pthread library (unless the thread is created in a detached state, which isn't the case here).
The signal handler will fail to initialize if |
A bug in signal_handler thread initialization led to an overcomplicated implementation of wait_for_signal_handler_to_end, namely that we could fail to initialize the signal handler but mark it as active anyway. This meant that we could wait for it to terminate when it didn't exist in the first place.
Additionally, let's immediately close down the signal handler loop when we decide to break connections--it's the start of process termination anyway, and there's no need to wait once we've invoked break_connections.