macos: fix gu_cond usage for darwin after 09848b6#25
Open
sitano wants to merge 1 commit intoMariaDB:mariadb-4.xfrom
Open
macos: fix gu_cond usage for darwin after 09848b6#25sitano wants to merge 1 commit intoMariaDB:mariadb-4.xfrom
sitano wants to merge 1 commit intoMariaDB:mariadb-4.xfrom
Conversation
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 <john.koepi@gmail.com>
sitano
force-pushed
the
ivan/fix_darwin_mutex_use
branch
from
ba3a04e to
6bed224
Compare
Author
|
@janlindstrom any chances for it to make it through? |
janlindstrom
force-pushed
the
mariadb-4.x
branch
2 times, most recently
from
530dcad to
73e530e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
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