Emil Dotchevski wrote:
Of course we want Microsoft to offer this threading model to C programmers, but it's the job of the C standard committee to define the exact syntax. This standard C syntax might as well be the exact POSIX syntax, no problem by me. But it doesn't really matter one way or the other, as long as the C syntax accepted is a good one. Doesn't this answer your original question, which was "why do we want Microsoft to ship a pthread layer"? They would have to, either way. Microsoft might as well have to implement a pthread layer, but that's non of our business, as long as they comply with the C/C++ standard.
Except that it is of benefit to the C++ community if the C and C++ layer are compatible beyond just syntax. N2178 defines interoperability semantics that go beyond standard pthread.
The only question left is whether we want two incompatible C APIs to the same underlying model, only one of which works on Windows, or just one. It seems to me that it is in our best interest to want the latter. We would have only one C API, and it will work on Windows. The allegedly second C API is hidden and non of us should care about it.
I would agree if we were talking about 2 substantially different APIs. Sure, if you have pthreads and something that's somewhat different, why not. The point is that pthread, with a few extensions, is exactly what we need from this hidden API.
Maybe so, maybe not. It's simply irrelevant. A hidden API is, well, hidden.
But let's turn things over: why not use pthread instead of creating another API? I think it is clear that using pthreads has a few advantages. What is the drawback?
That's it's not good C++. We are designing a C++ interface here, and we want to take advantage of all the nice things C++ has to offer, as Sohail pointed out. N2184 is better at using all those nice things, IMO. I don't want to damage that for this compatibility. I just don't think it worth it.