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: Joseph Myers <joseph at codesourcery dot com>
- To: Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Fri, 19 Jun 2015 17:00:54 +0000
- 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> <CAD82F-qNPdSqDE2d+aBm=jUp5TfJHw3fzo2bYb0KasDv6WFxwQ at mail dot gmail dot com>
On Fri, 19 Jun 2015, Juan Manuel Torres Palma wrote:
> 2015-06-18 16:12 GMT+02:00 Joseph Myers <joseph@codesourcery.com>:
>
> > 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 have done that, but still have some code duplication (different
> mutex types for x86_64 and x86) but I think is acceptable because the
> code is easy to read. I could fix it splitting it in several macros,
> but I think it will look a bit more messy. However I will do it if
> needed, I'm still learning :)
This is looking closer to what I'd expect if we do go with the same layout
of C11 and POSIX threads types (subject of course to updating all
architectures similarly). Now, I don't see any reason for
bits/threadstypes.h to be architecture-specific. Furthermore, maybe the
parts of bits/pthreadtypes.h that now just use the *_CONTENT macros
shouldn't be architecture-specific either (that is, they should be in a
new bits/ header with only one version of that header in the tree).
--
Joseph S. Myers
joseph@codesourcery.com