This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Fixing pthread_* namespace issues for thrd_* symbols
- From: Torvald Riegel <triegel at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>, Szabolcs Nagy <nsz at port70 dot net>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 18 Jun 2015 18:20:48 +0200
- Subject: Re: [RFC] Fixing pthread_* namespace issues for thrd_* symbols
- Authentication-results: sourceware.org; auth=none
- References: <CAD82F-pVYZvT+HHK4XchTeSEFeOUQoUBwtFA=-b52zs8i+_bJw at mail dot gmail dot com> <20150430162657 dot GD863 at port70 dot net> <CAD82F-raesW2rAFEaMO_CYtyaXVmEAfeQa2Fi3vOXLwc-TyTEg at mail dot gmail dot com> <20150501131002 dot GA29166 at port70 dot net> <CAD82F-qqRsNwymfdXOEuHRGedBq1SjtqgjZO5poyDDzExRs0_g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1506181411020 dot 31642 at digraph dot polyomino dot org dot uk>
On Thu, 2015-06-18 at 14:12 +0000, Joseph Myers wrote:
> On Thu, 18 Jun 2015, Juan Manuel Torres Palma wrote:
>
> > Sorry for late reply.
> >
> > My solution so far is this one, only for x86, will work on other
> > architectures as long as this strategy is acceptable. What I have
> > mainly done is copy pthread_mutex_t and pthread_cond_t renaming them,
> > so I won't be breaking any ABI and namespaces will be clean. Let me
> > know if it's acceptable.
>
> Contents shouldn't be duplicated, but you could e.g. have a shared header
> that defines macros such as __PTHREAD_COND_T_CONTENT, so cnd_t would be
>
> typedef union
> {
> __PTHREAD_COND_T_CONTENT
> } cnd_t;
>
> and pthread_cond_t similarly.
>
I'm still not convinced that we should just create thrd_* data
structures that are the same size as pthread_*, especially for mutex.
I'm aware we have discussed this before, and using the same size might
be considered a safe bet -- however, we certainly don't need a robust
mutex list pointer for C11, nor do we know that a larger pthread_* type
would be sufficiently large for whatever we might want to do in the
future with the thrd_* types.
Also, just copying the algorithms isn't ideal in every case. For
example, C11 mutex has different semantics than various POSIX mutex
types, which affects lock elision:
https://sourceware.org/glibc/wiki/LockElisionGuide
Also, we don't need to distinguish between mtx_plain and mtx_timed, nor
between recursive and non-recursive, I believe.
condvar semantics are the same IIRC. We could make the cnd_t struct
smaller than current pthread_cond_t, but that is probably not as
relevant for performance as in the case of mutex, which could be
embedded with the data they are supposed to protect.