Re: [boost] Boost.Threads, N2178, N2184, et al

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-03-22 06:29:24

Alexander Terekhov <terekhov_at_[hidden]> 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