This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ISO C11 issues for glibc


On Wed, 21 Dec 2011, Roland McGrath wrote:

> As for __STDC_NO_THREADS__, I've only glanced at (the draft I could find
> of) the spec.  But it looks like implementing those as a layer on top of

There should be no technical changes between N1570 and the final standard, 
since the DIS was approved in ballot with no comments.  (ISO rules mean 
that N1570, the DIS with diff marks against the previous draft, is public 
but N1569, the DIS without those diff marks, isn't.  Unfortunately I don't 
think there's a version of the DIS with diff marks relative to 
C99+TC1+TC2+TC3, although N1548 was such a version of the previous draft.)

> Given how simple it looks to support the ISO C threads interfaces as
> wrappers, it seems worthwhile to just do that now rather than bother with
> an immediate __STDC_NO_THREADS__ change and leave the wrappers for later.
> But perhaps there is some complexity or drawback I've overlooked (I've
> really only glanced at the new spec, and only at an older draft).
> 
> What do you think?

It's meant to be a reasonably simple wrapper around other threading 
interfaces, and implementing it would certainly be reasonable, and useful 
if this does take off as a threading interface used in portable code - at 
the same time it's clear that while most of the features should be very 
straightforward to implement, this one and uchar.h do probably involve 
more work than the rest (as does stdatomic.h, although given the language 
features that should mostly be a fairly simple wrapper round GCC built-in 
functions as well).

A static-only -lthrd as you suggest (with the usual license exception 
notice that goes in files in libc_nonshared.a etc.), with 
bits/pthreadtypes.h defining only reserved-namespace names, certainly 
seems a sensible technical approach.

Maybe it makes sense to put features in one at a time, starting with the 
feature test macro for C11 - and then if by the 2.15 branchpoint, whenever 
that is, this optional feature hasn't been implemented (whether or not the 
C11 support is otherwise complete), put in __STDC_NO_THREADS__ before 
making the 2.15 release.

(The Santa Clara WG14 minutes (N1375) say "Ulrich would prefer that this 
feature be made optional. He does not want to use it, and doesn't want to 
be required to implement it.".  So that's one starting point for a 
presumption that other C11 features are going to be less controversial 
than this one.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]