From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-10-06 06:53:10
Roland Schwarz <roland.schwarz_at_[hidden]> writes:
> Anthony Williams wrote:
>> On Windows we don't need two calls to call_once, as my implementation allows
>> passing an arbitrary functor, which can therefore have state (e.g. use bind to
>> pass parameters).
> Hmm, I remember there was a sound reason why Bill Kempf ommitted
> parameters deliberately. Not sure about this, I will need to try
> to find the respective discussion thread.
They are hard to do on POSIX, since pthread_once doesn't allow it.
>> Your code demonstrates how we could provide the same facility with pthreads,
>> as an extension to call_once. Incidentally, whilst we're thinking about this,
>> the POSIX spec says:
> Indeed I have shamelessly stolen the idea from looking at Bill Kempfs
> call_once implementation for pthreads. He is using this there also,
> altough I think, superfluously.
As it stands, this is superfluous, and doesn't actually get round the issue.
>> "The behavior of pthread_once() is undefined if once_control has automatic
>> storage duration or is not initialized by PTHREAD_ONCE_INIT."
>> So we need to document this restriction on the use of boost::once_flag, unless
>> you can find a way round it. This restriction doesn't apply on Windows, at
>> least not with my implementation.
> I suspect this is because you are relying on zero initialization, right?
Yes, my once_flag is just a long, BOOST_ONCE_INIT is 0. That works fine at any
scope/storage duration. Obviously, if you exit the enclosing scope, so the
once var is destroyed, and then reenter the scope, so it is reconstructed,
then the once call will be made again.
-- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk