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 ;-)
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?
So, what about sockets, asynchronous I/O etc? <with some twinkle in eye> For asynch I/O I'd promote to code against the NT abstraction, where the OS was built and designed from ground up with asynchronous I/O support in the kernel. Or, even better, the superior VMS I/O model. And then, vendors should implement SYS$QIO, SYS$WAIT, SYS$SYNCH, et al ... </with some twinkle in eye>
This stance is obviously unsustainable if there are strong technical reasons against it. But I think that there aren't.
I'd be surprised if there were no performance considerations at all. I realize that C programmers also need portable threading support, but requiring the C++ implementation to use a specific underlying API is not the way to go, IMHO.
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. ;-)
Almost everything is possible with lots of effort. I don't know about this particular case. / Johan