Alexander Terekhov <terekhov@web.de> writes:
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 ;-)
http://www.infoworld.com/articles/pl/xml/02/07/29/020729plmsu.xml (REVIEWS: A nod toward Unix... PROS: + Bypasses Win32 API for performance + Superior performance to Win32 API + Price is unbeatable)
All a bit vague. It might well give better performance to code UNIX APIs directly in terms of the Windows native API rather than the Win32 API. It makes sense to me --- the fewer abstraction layers between user code and the underlying OS, the better. That's actually precisely my argument above. Note also that V3.0 is being reviewed, which doesn't include pthreads.
http://www.microsoft.com/technet/interopmigration/unix/sfu/pthreads0.mspx
Demonstrating that it is possible to code pthreads in terms of the native Windows API, especially if you're writing a whole UNIX-interop layer, including a full POSIX C library. Anthony -- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL