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] |
On Fri, 2013-06-21 at 12:48 +0200, Torvald Riegel wrote: > On Thu, 2013-06-20 at 21:23 -0400, Rich Felker wrote: > > On Thu, Jun 20, 2013 at 08:34:31PM +0200, Torvald Riegel wrote: > > > Carlos asked me to send a more detailed plan for how we could split up > > > Andi's work so that we can commit the parts that we can (hopefully) get > > > consensus on before the freeze. This might have some rough edges, but > > > should show what I have in mind. Comments? > > > > > > 1) Give PTHREAD_MUTEX_DEFAULT a new enum value != 0 (and thus not equal > > > to PTHREAD_MUTEX_NORMAL's value) > > > > I agree this would be a better choice than changing the value of > > PTHREAD_MUTEX_NORMAL. However, I have one additional idea: what about > > swapping the two values when they move from pthread_mutexattr_t to > > pthread_mutex_t? That way, existing mutexes initialized by > > PTHREAD_MUTEX_INITIALIZER would have default type (and thus could use > > elision) rather than having normal type. This is the approach we'll > > probably use in musl if we add elision at some point. > > Right, and that's the direction we discussed in the 2.18 thread just a > while before you posted this. Please have a look. Attached is a start of a patch to clarify what I mean. What is obviously missing is handling the new PTHREAD_MUTEX_NORMAL_INT_NP in all of the mutex functions, but that should be rather straight-forward, I assume. Comments? > > On the other hand, glibc has non-default-type mutex initializer > > macros, so we might have to consider whether any of them are > > documented to have the "normal" behavior rather than the "default" > > behavior. I'm not clear on this. I think the other initializers are fine because they initialize to kinds != DEFAULT already, so there's no ambiguity there, and we can just decide whether we want to use elision for those or not.
Attachment:
patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |