Re: [RFC] Fixing pthread_* namespace issues for thrd_* symbols

[Rich Felker <dalias at libc dot org>]

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