Re: [PATCH][BZ #14417] Unlock mutex before going back to waiting forPI mutexes

["H.J. Lu" <hjl dot tools at gmail dot 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.