Update on freeze status of glibc 2.18?

[Andi Kleen]

If you're looking for consensus, there's no consensus from me
for the DEFAULT != NORMAL proposal. Please don't discuss 
it like there is. In fact I totally object to it.

As I explained earlier even with elision there will be eventually
deadlocks for such programs, just not all the time.
So the "deadlock requirement" is mostly followed.

I think the disadvantages (disabling elision for all programs)
totally outweight the advantages (do something that is unlikely
to affect any real program)

How many programs do you have deadlocking and it's not a bug?

>From my point (and why I did this glibc elision project) the main
advantage of enabling elision in pthread is working with existing
programs and binaries.  If that is broken, and every application
would have to be manually modified, the value for me is gone.

The point of releasing it to users for testing would be also moot because
the testing coverage would be very limited if it's not enabled.

If everything would need to be modified it alo doesn't make a lot of sense
to use pthread locks at all, but a more modern optimized and less overhead
locking interface.

But working with existing code bases and binaries is important.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.