[Patch] C1X threading support

[Niall Douglas]

On 19 Dec 2011 at 17:31, Daniel Eischen wrote:

> > Obviously, had we known that from the beginning, things would have
> > been done differently. However, there was - in hindsight - a lack of
> > realisation just how expensive any significant changes would appear
> > to vendors.
> 
> And why on earth would the thought of having a threading API
> significantly different from the POSIX API even be on the
> table?  It boggles the mind.

1. Because POSIX threads is known to have weaknesses in its design 
e.g. signal handling. These BTW have been fixed in C1X and there are 
some significant departures from the POSIX API wherever pthreads was 
just plain broke. Some of these departures may - on some platforms - 
require rejigging the internal kernel/userspace boundary. Before you 
ask, no I don't know what these are, it isn't my area of expertise.

2. Because pthreads were designed a long time ago in a world where 
threading was simpler and likely core count was lower. There are more 
use models now, and originally it was thought that incorporating some 
elements of newer threading models would be wise. Bear in mind that 
C1X - unlike POSIX - has to incorporate EVERY kind of computing 
system thinkable. C1X needs to run - without major baggage - on 
everything from tiny, OSless systems right up to thousand CPU core 
highly proprietary systems. And it must do this while staying as 
backward compatible with legacy systems as possible.

3. Because pthreads is not the only major threading implementation 
out there. The NT/OS/2 model is hugely popular if fundamentally 
anti-scalable in design and pthreads don't map exactly one to one 
with them. For example, thread cancellation is completely missing 
from C1X as it would require significant kernel rewriting on NT, so 
it got chopped completely. It had been hoped we could come up with 
something which worked around the lack of thread cancellation, but we 
didn't make it in time. It'll be TR1 before we nail the corner cases. 
Right now, there are quite a few places where under the C1X API the 
program will just hang if things go wrong and there is no legal way 
out at all. That is unfortunate, but as always it's a question of 
resourcing and time. Most people's employers don't see how investing 
in standards work improves their bottom line, so a lot of the grunt 
work is goodwill and hobby time.

4. Because POSIX does evolve over time - indeed, its next release is 
same year as C1X (i.e. next year). People sit on both ISO committees 
and are on the Austin Working Group. There is significant 
cross-pollination. The changes in C1X are highly likely to become 
normalised in the next iteration of POSIX. So think of this way, the 
departures from POSIX in C1X were mostly intended as departures by 
POSIX from POSIX next iteration anyway.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.