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: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT


On Tue, Jun 25, 2013 at 01:40:13PM -0700, Andi Kleen wrote:
> > > commit 61dd6208fb1e59a423b6dfa712a3c896c34b2590
> > > Author: Siddhesh Poyarekar <siddhesh@redhat.com>
> > > Date:   Sat Jun 15 12:24:15 2013 +0530
> > > 
> > >     New API to set default thread attributes
> > > 
> > > Why are any additions I make suddenly such a big problem?
> > 
> > A new API is very different from a new ABI version of an existing API.
> 
> The patches to implement the new version of gettype / the new NORMAL
> is already separate.  Also if it's really a problem we can drop it
> and just do what the original patches did.
> 
> The other patches don't add any new versions, just two new bits
> to two existing APIs (enable/disable elision for mutexes and
> rwlocks respectively)
> 
> Also all of these patches have been already reviewed by multiple
> people, including Carlos.

And as I understand it they will be applied in either their current
form or something very close to it.

> > Also, the tuning per-lock is not nearly as impactful as adding mutex
> > type constants or changing the meaning of existing ones in subtle
> > ways. Adding these new tuning functions will not affect any
> > application that does not use them, i.e. any current application and
> > any conforming POSIX application. On the other hand, changing NORMAL
> > will affect many applications.
> 
> FWIW i spent quite some time on debian codesearch and koders.com 
> and I determined that NORMAL or pthread_mutexattr_settype(DEFAULT)
> is not widely used at all. That was the only reason I agreed to
> disable elision for NORMAL and plain settype() on old binaries.

That's only a search of FOSS code. glibc is not for exclusive use by
FOSS projects. In fact I would surmise the majority of seriously
multi-threaded code using glibc is not FOSS, since FOSS developers, at
least per my own anecdotal experience, tend to be allergic to threads
and demand complex libevent/epoll/etc.-based event loops and state
machines instead.

Rich


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