This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc -- ISO C11 threads Proposal
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>, Rich Felker <dalias at aerifal dot cx>
- Cc: Kevin Cox <kevincox at kevincox dot ca>, Torvald Riegel <triegel at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 26 Mar 2014 23:16:48 -0400
- Subject: Re: glibc -- ISO C11 threads Proposal
- Authentication-results: sourceware.org; auth=none
- References: <53260E7E dot 8070308 at kevincox dot ca> <1395771092 dot 19076 dot 1236 dot camel at triegel dot csb> <5331C7EA dot 6050407 at redhat dot com> <1395777699 dot 19076 dot 1469 dot camel at triegel dot csb> <20140325212732 dot GC26358 at brightrain dot aerifal dot cx> <53337E8B dot 50508 at kevincox dot ca> <20140327015642 dot GF26358 at brightrain dot aerifal dot cx> <20140327023659 dot E74C57449C at topped-with-meat 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.