Peter Dimov wrote:
Johan Nilsson wrote:
Peter Dimov wrote:
Anthony Williams wrote:
For a non-pthreads platform, it might make sense to implement pthreads in terms of the C++ interface, which is implementes in terms of the native API, rather than implement the C++ interface in terms of pthreads, which is then implemented in terms of the native API.
Yes, this is possible, and there are no technical reasons to avoid this implementation approach. There are, how should I put that, ideological reasons to not target non-pthread platforms directly, though.
Wow, this caught my eye when lurking around. Are we promoting Windows-bashing for its own sake here ;-)
No, you misunderstood.
We are promoting ISO/IEC 9945 as a standard threading abstraction.
IIUC that is "The Single UNIX Specification", I assume you mean the "pthread.h" part of it?
We are (hypothetically) providing an implementation for Windows as a service to the users/developers and as a proof of viability. We are encouraging Microsoft to supply its own implementation because they can do it better than us with access to the kernel.
Even if they did, that'd have to be implemented as an update or add-on for current platforms. Requiring post-Vista versions of Windows for having threads available under C++ doesn't seem right to me. Also, what about unsupported OS's such as NT4? Microsoft will never release any officially supported updates to such platforms. Basically, what I'm saying is that any Win32 C/C++ thread implementation still has to provide its own threading support as it can't rely on pthreads being available. Or, sorry, was that what you actually meant, that the standard C++ library would "have to" include kernel modules for best performance under Windows? Am I still misunderstanding? I have a nagging feeling that I do ...
I'd be surprised if there were no performance considerations at all.
One would expect a C++ programmer to be more careful with that argument, given his constant exposure to C programmers who really would be surprised if using C++ doesn't make their code slower. ;-)
Touché. But, still - without any firm evidence I believe that "C++ -> pthreads layer -> Win32 threads" is slower than "C++ -> Win32 threads", which is what I based my assumption upon.
That aside, if there is a legitimate design-imposed source of inefficiency in N2178, I'll be glad to know about it so that it can be fixed.
I never said it was. To be honest though, I've only glanced at the proposal, so I'll give it another shot. / Johan