Re: glibc -- ISO C11 threads Proposal

["Carlos O'Donell" <carlos at redhat dot com>]

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.

> Compartmentalization would mean things like adding a new DSO
> with a separately floating SONAME and version sets, with libc.so or
> libpthread.so or whatever including INPUT ( AS_NEEDED ( libfoo.so.N ) ).

That will require some surgery from a core developer, but it's possible,
I don't expect a GSoC student to do this on their own. I'll think about 
this as I'm the mentor for the student.

> Those approaches have some overhead, but they also gain us a great deal of
> flexibility for the future.  This can make us much less reticent to add new
> interfaces and much less paranoid about getting them perfectly right the
> first time or holding them back until we're thoroughly confident.  We can
> essentially deploy prototypes and let them cook in the real world for a
> while before circling back to decide what's worth optimizing more or
> differently and (perhaps, when appropriate) baking into the core libc.so.6
> permanent ABI.  With this model, we can let new volunteers, GSoC students,
> etc., just go to town on new stuff and get it hashed out concretely without
> (or at least before) making them extrude themselves through our extremely
> narrow bottleneck of permanent ABI conservatism a priori.

Just to be clear you're suggesting that the new alternate libraries carry
no ABI requirements and we make that clear how?

Won't users just start using C11 threads and claim libfoo.so.N is just as
important to their applications as libc.so.6?

I don't disagree with the position that we can deploy an unstable library,
and provide no guarantees. I'm just being the devil's advocate here.

Cheers,
Carlos.