Yuval Ronen wrote:
Peter Dimov wrote:
Anthony Williams wrote:
However, Microsoft do not supply such an interface, so someone has to write one. Writing one might be a good idea, but using it to implement the C++ API, when the C++ API could be better written using the win32 API directly seems a bad plan to me, especially if you could use your C++ API to implement pthreads.
It depends on what your plan is supposed to achieve. If you want to gradually transition from where we are now to a point where Microsoft does supply a pthread layer, it's not a bad plan at all. If you want something else, it might or might not be, depending on what exactly do you want. Anyway, I see that you are taking this as an argument, so I'll leave you to your opinion.
Excuse me for being a bit daft here, but why is our plan to make Microsoft supply a Windows pthread layer? The reason we all want that today, is because there *is no* C/C++ threading standard. Once there is such a standard, we wouldn't care anymore about the underlying OS API. That's the whole purpose of this (or any) standardization effort, isn't it?
That was the exact purpose of the pthreads standard. Now people on POSIX-compliant OSes don't care about the underlying OS APIs (which in general have little to do with pthreads) because the vendor ships a pthread layer. Add to that the fact that all threading proposals to date agree that the pthreads threading abstraction is the way to go; they all mandate its set of primitives and semantics. So we do want Microsoft to offer the pthread threading model to C++ programmers, even if some of us don't realize it. The obvious question now is: do we want Microsoft to offer this threading model only to C++ programmers and not to C programmers? And what do we stand to gain from that? How is it in the best interest of the C++ community to demand that C code remains nonportable?