|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-21 17:10:10
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. ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk