Re: glibc -- ISO C11 threads Proposal

[Roland McGrath <roland at hack dot frob dot com>]

> 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