This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- From: Rich Felker <dalias at aerifal dot cx>
- To: Andi Kleen <ak at linux dot jf dot intel dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 25 Jun 2013 16:57:16 -0400
- Subject: Re: [PATCH] Add PTHREAD_MUTEX_NORMAL_INT
- References: <1372105055-31254-1-git-send-email-andi at firstfloor dot org> <51C8AB50 dot 80108 at redhat dot com> <20130624203147 dot GO5643 at tassilo dot jf dot intel dot com> <51C8B797 dot 7080503 at redhat dot com> <20130624232607 dot GT6123 at two dot firstfloor dot org> <51C9B7D0 dot 5000207 at redhat dot com> <20130625170656 dot GB6123 at two dot firstfloor dot org> <20130625173203 dot GL29800 at brightrain dot aerifal dot cx> <20130625204013 dot GS5643 at tassilo dot jf dot intel dot com>
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