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: Torvald Riegel <triegel at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, Kevin Cox <kevincox at kevincox dot ca>, libc-alpha at sourceware dot org
- Date: Sat, 29 Mar 2014 00:09:55 -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> <1395937708 dot 19076 dot 2997 dot camel at triegel dot csb> <20140327170447 dot GJ26358 at brightrain dot aerifal dot cx> <53350719 dot 6090401 at redhat dot com> <1396037936 dot 19076 dot 4039 dot camel at triegel dot csb>
On 03/28/2014 04:18 PM, Torvald Riegel wrote:
>> A minimal C11 synchronization object has no room for error, it has
>> to be right the first time. If my experience has taught me anything
>> is that eventually everything is wrong. Starting with C11 objects
>> that are the size of pthread ones is as good a starting place as
>> any.
>
> What do you think is the likelihood of us actually down-sizing the mutex
> types eventually? Do you really think this will happen?
The likelihood is 0 once we release an implementation for general use.
We never changed when we went from Linuxthreads to NPTL, in fact
we made sure that structures were at least their Linuxthreads sizes
to avoid any ABI effects.
I don't expect us ever to change the size or alignment of the type
once it becomes available for public use.
That says nothing about the internal layout or which bits we use for
what.
The other questions I have are:
* Do we hinder C11 adoption by not having C11 threads.h available
as soon as possible?
* Do we help C11 adoption by having C11 threads.h based on a stable
and well tested threading implementation?
>> I have always lamented that pthread objects didn't have some
>> extra space for debugging information, and the recent elision usage
>> of some remaining unused bits only goes further to remind me that
>> free space is nice to have.
>
> But "nice to have" comes with a cost.
That it does.
The alternative is a "from scratch" C11 threads.h implementation.
We can always eventually optimize the implementation to provide
tighter semantics, but the object sizes will likely always
remain the same.
Cheers,
Carlos.