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.