This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]