This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc -- ISO C11 threads Proposal
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Kevin Cox <kevincox at kevincox dot ca>, Torvald Riegel <triegel at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 26 Mar 2014 19:36:59 -0700 (PDT)
- 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>
> 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.) 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 ) ).
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.
Thanks,
Roland