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: Rich Felker <dalias at libc dot org>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, 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 16:00:04 -0400
- 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> <1434644448 dot 30819 dot 10 dot camel at localhost dot localdomain> <20150618175323 dot GN1173 at brightrain dot aerifal dot cx> <1434656225 dot 3061 dot 5 dot camel at localhost dot localdomain>
On Thu, Jun 18, 2015 at 09:37:05PM +0200, Torvald Riegel wrote:
> On Thu, 2015-06-18 at 13:53 -0400, Rich Felker wrote:
> > On Thu, Jun 18, 2015 at 06:20:48PM +0200, Torvald Riegel wrote:
> > > 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.
> >
> > Actually you _do_ need robust list pointers if the committee decides
> > that the behavior is well-defined when a thread exits with a recursive
> > mutex held. The only way to implement this efficiently is to have a
> > linked list of all mutexes the thread holds so that they can be
> > changed to a permanently-locked state immune to tid reuse. I think the
> > possibility of needing to make this change, even if you think it would
> > be an unwanted change now, is a _major_ argument for keeping the
> > same-sized structures.
>
> But that's just accidental. There may be other potential changes to the
That's your view; I'm not clear what the committee's will be. But as
is, requiring the tracking would not be a change to the standard; it
would be sticking with the requirements of the standard-as-written
rather than considering those requirements a defect (which they may
be, as you think they are) and changing the text so that they're no
longer required.
> standard that we're not aware of right now, so we don't really know
> whether the same size would be sufficient, less would be sufficient, or
> we'd actually need a bigger structure.
>
> Maybe we should let the committee clarify that before giving ABI
> stability guarantees for mtx_t.
I would just go with the already-discussed type sizes rather than
leaving C11 threads support pending indefinitely waiting for the
committee's response, but I agree it would be good to go ahead and try
to push the issue forward as a request for interpretation. Any such
request should cite the Austin Group issue (which was ruled the other
direction) so it's clear that you're asking for a license for C11
recursive-mutex semantics to be more relaxed/lest-costly to implement
versus POSIX ones.
Rich