macos: fix gu_cond usage for darwin after 09848b6 #25
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