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

macos: fix gu_cond usage for darwin after 09848b6 #25

Open
wants to merge 1 commit into
base: mariadb-4.x
Choose a base branch
from

Conversation

sitano
Copy link

@sitano sitano commented Aug 28, 2024

macos: fix gu_cond usage for darwin after 09848b6

the patch 09848b6 by Jan from 2021-11-11 14:22:24 +0200 that swapped the
order of the arguments to gu_mutex_init_SYS. so now its
gu_mutex_init_SYS(const wsrep_mutex_key_t* key, gu_mutex_t_SYS *mutex)
so that for keyless mutexes its using (NULL, &mutex).

considering GU_BARRIER_THREAD_SYS replacement:

it was introduced by dabe053 8 years ago, but I suppose it never
compiled as at that moment there were no GU_BARRIER_THREAD_SYS.

it is synonymous to PTHREAD_BARRIER_SERIAL_THREAD that is must return
something non-usual on success (here its -1) for a thread synced with a
barrier as per POSIX https://linux.die.net/man/3/pthread_barrier_wait

The constant PTHREAD_BARRIER_SERIAL_THREAD is defined in
<pthread.h> and its value
shall be distinct from any other value returned by
pthread_barrier_wait().

Upon successful completion, the pthread_barrier_wait() function shall
return PTHREAD_BARRIER_SERIAL_THREAD for a single (arbitrary) thread
synchronized at the barrier and zero for each of the other threads.

there is no such a constant in the code GU_BARRIER_THREAD_SYS.

follow up #20
CI https://buildbot.mariadb.org/#/grid?branch=refs%2Fpull%2F25%2Fmerge

the patch 09848b6 by Jan from 2021-11-11 14:22:24 +0200 that swapped the
order of the arguments to gu_mutex_init_SYS. so now its
`gu_mutex_init_SYS(const wsrep_mutex_key_t* key, gu_mutex_t_SYS *mutex)`
so that for keyless mutexes its using (NULL, &mutex).

considering GU_BARRIER_THREAD_SYS replacement:

it was introduced by dabe053 8 years ago, but I suppose it never
compiled as at that moment there were no GU_BARRIER_THREAD_SYS.

it is synonymous to PTHREAD_BARRIER_SERIAL_THREAD that is must return
something non-usual on success (here its -1) for a thread synced with a
barrier as per POSIX https://linux.die.net/man/3/pthread_barrier_wait

> The constant PTHREAD_BARRIER_SERIAL_THREAD is defined in
<[pthread.h](https://linux.die.net/include/pthread.h)> and its value
shall be distinct from any other value returned by
pthread_barrier_wait().

> Upon successful completion, the pthread_barrier_wait() function shall
return PTHREAD_BARRIER_SERIAL_THREAD for a single (arbitrary) thread
synchronized at the barrier and zero for each of the other threads.

there is no such a constant in the code GU_BARRIER_THREAD_SYS.

Signed-off-by: Ivan Prisyazhnyy <[email protected]>
@sitano sitano force-pushed the ivan/fix_darwin_mutex_use branch from ba3a04e to 6bed224 Compare August 28, 2024 08:04
@sitano
Copy link
Author

sitano commented Dec 16, 2024

@janlindstrom any chances for it to make it through?

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

Successfully merging this pull request may close these issues.

1 participant