This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ #14417] Unlock mutex before going back to waiting forPI mutexes
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Torvald Riegel <triegel at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 3 Oct 2012 06:48:10 -0700
- Subject: Re: [PATCH][BZ #14417] Unlock mutex before going back to waiting forPI mutexes
- References: <20120921195115.2319b183@spoyarek><1348943552.3374.5816.camel@triegel.csb><20121001112156.05223618@spoyarek><5069BAFA.7060504@redhat.com>
On Mon, Oct 1, 2012 at 8:47 AM, Jeff Law <law@redhat.com> wrote:
> On 09/30/2012 11:51 PM, Siddhesh Poyarekar wrote:
>>>
>>> I would be surprised if a single branch after a syscall would be a
>>> measurable performance degradation. Not sure what the policy for this
>>> is, but I'd prefer an abort or such if we get a return value we didn't
>>> expect. Also, if we get frequent spurious wake-ups, then this branch
>>> is the smallest part of the overhead.
>>
>>
>> I got the impression in the past that the nptl code had to be as
>> trim as possible, which is why I left it out on purpose. If the abort
>> is OK in this for others, I'll put it in.
>
> I'd go without the abort in this case -- primarily because glibc hasn't
> introduced aborts for this kind of "can't or shouldn't happen" behaviour as
> liberally as other projects (such as GCC). I'm not aware of any in the hand
> written assembly bits, which were written presumably to be absolutely as
> fast as possible.
>
We abort when something bad happens, at least in ld.so and nptl,
see nelf/dl-reloc.c, ptl/forward.c and nptl/unwind.c
--
H.J.