This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Lock Elision / Transaction ABI discussion
- From: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>
- To: libc-alpha at sourceware dot org
- Cc: triegel at redhat dot com, andi at firstfloor dot org
- Date: Mon, 16 Sep 2013 15:52:43 +0200
- Subject: Re: Lock Elision / Transaction ABI discussion
- Authentication-results: sourceware.org; auth=none
- References: <20130916133554 dot GA20561 at linux dot vnet dot ibm dot com>
- Reply-to: libc-alpha at sourceware dot org
One concern I have with a glibc-only-ABI is that abort codes are
infectious. If you have libraries libfoo and libbar that both
use explicit abort codes, they need to know about each other even
if the developers are not aware of this. The explicit abort codes
of libfoo pollute the abort code range that is available to libbar
or glibc, and all the libraries need to know that.
So, if glibc reserves some abort codes in an ABI, that only solves
the resource conflict locally. Other variants of a c library need
to adhere to the same rules as glibc. Furthermore, while z has
64-bit abort codes, Intel's Tsx has only 8-bit user define abort
status codes, so available space is scarce.
Hence the suggested rule not to use explicit abort codes for code
flow control.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany