From: Peter Dimov (pdimov_at_[hidden])
Date: 2007-03-22 08:31:26
Anthony Williams wrote:
> OK. But that doesn't really address my initial point: implementing
> call_once in terms of the POSIX pthread_once is a bit pointless if
> you need to implement pthread_once separately anyway. If you don't
> have pthread_once, I would write call_once (or, equivalently
> pthread_once2_np), and implement pthread_once in terms of that.
This is tied to another issue, whether the implementation should be
header-only. If one is committed to produce a header-only implementation, it
makes sense to reuse your current call_once in the implementation of
pthread_once (and possibly pthread_once2_np).
The N2178 pthread.h aims to support the scenario where one is to deliver a
separately compiled pthread-win32.lib/dll (as part of the Platform SDK, say
;-) ). This is why I've tried to make sure that the C++ templated layer is
implementable without loss of performance or generality in terms of a
non-templated API (which happens to be a slightly extended pthreads layer).
With careful definitions of the pthread_* types, it's possible to achieve
binary compatibility as well, that is, link the program against a newer
version of pthread-win32.lib/dll and have it work without recompilation.
This is not possible with header-only templates or inline functions, because
they are burned into the application code at compile time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk