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. At some point we need to draw a line and say: this is the thread abstraction we're coding against, and could vendors please get along with the program? This stance is obviously unsustainable if there are strong technical reasons against it. But I think that there aren't.
Lets take call_once, for example. PThreads only allows a real function with no parameters returning void as the once function. This is relatively easy to implement on top of a C++-style call_once that allows arbitrary function objects with parameters, whereas it is much harder to do the reverse.
There is a note in N2178 that shows how to implement call_once on top of pthread_once2_np. ;-)