This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Where does MUTEX_INITIALIZER come from on Hurd?
- From: Samuel Thibault <samuel dot thibault at ens-lyon dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 4 Nov 2015 18:07:13 +0100
- Subject: Re: Where does MUTEX_INITIALIZER come from on Hurd?
- Authentication-results: sourceware.org; auth=none
- References: <563A388E dot 1090906 at redhat dot com>
Florian Weimer, on Wed 04 Nov 2015 17:55:42 +0100, wrote:
> We currently have malloc-machine.h and libc-lock.h. For NPTL targets,
> malloc-machine.h provides MUTEX_INITIALIZER. But Hurd malloc-machine.h
> does not provide it, and libc-lock.h references it. Where does it come
> from?
It comes from cthreads.h, outside of glibc:
libthreads/cthreads.h:#define MUTEX_INITIALIZER { SPIN_LOCK_INITIALIZER, SPIN_LOCK_INITIALIZER, 0, QUEUE_INITIALIZER, }
> The libc-lock.h wrappers currently do not seem to provide *any*
> replacement for MUTEX_INITIALIZER. Should we assume that
> zero-initialization works for mutexes?
It will happen to work with the current cthreads implementation, but
that's not guaranteed.
Samuel