glibc -- ISO C11 threads Proposal

[Rich Felker]

On Wed, Mar 26, 2014 at 11:16:48PM -0400, Carlos O'Donell wrote:
> On 03/26/2014 10:36 PM, Roland McGrath wrote:
> >> So in that case, the object sizes (for ABI purposes) will match the
> >> pthread ones. Is that ok with everyone?
> > 
> > We haven't discussed the broader ABI plan for these interfaces at all yet.
> > My inclination for all new major subsystem sort of interfaces is to add
> > them in ways that minimize and/or compartmentalize our permanent ABI
> > commitment.  Strictly minimizing would mean things like just having
> > statically-linked wrappers in lib*_nonshared.a, so in this instance there
> > might be no new ABI load at all--just compile-time wrappers around existing
> > pthread ABIs.  (I'm not particularly advocating that, it's just an
> > example.) 
> 
> That seems like a option as long as it's possible to do that and meet
> the requirements of the standard.

It's not an option with the current libpthread since the namespace
would be violated. Also, this nonshared approach makes a MUCH WORSE
ABI problem than doing things the right way; consider what happens
when the main program was linked against one version of the nonshared
lib, one of the .so's it uses was linked against a different version
of it, and both are using C11 threads. Please, don't take us down that
road.

The size of the synchronization objects needs to be a fixed ABI that's
intended not to change, and that will be adjusted with symbol
versioning if it ever does change. (Note: symbol versioning does
nothing for the API breakage which becomes ABI between multiple
third-party libraries/applications using these types.) Then everything
else can be changed freely in the internals without breaking
applications or libraries using C11 threads. I believe the pthread
types are plenty large to give the needed flexibility for any
reasonable implementation of C11 threads, and while smaller types
would probably also work, I think using the exact same sizes is a
simple choice that's also nice in that it allows (but doesn't require)
implementing the C11 functions using the pthread ones.

Rich