Skip to content
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

Open
wants to merge 1 commit into
base: 10.5
Choose a base branch
from

Conversation

DaveGosselin-MariaDB
Copy link
Member

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.

@DaveGosselin-MariaDB DaveGosselin-MariaDB self-assigned this May 13, 2024
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

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.
Copy link
Member

@vuvova vuvova left a 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);
Copy link
Member

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

Copy link
Member Author

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.

Copy link
Member Author

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).

@DaveGosselin-MariaDB
Copy link
Member Author

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?

The signal handler will fail to initialize if my_thread_global_init_done is false, which is possible and expected in some of our tests (I don't recall which at the moment, but I think in certain plugins).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants