Re: [boost] call_once on win32

From: John Maddock (john_at_[hidden])
Date: 2005-09-08 04:49:18

>>> If we store the return value along with the once_flag, then we really 
>>> ought
>>> to destroy it properly, when the once_flag is destroyed. If a once_flag 
>>> has
>>> static storage duration, and has a non-trivial destructor that does
>>> cleanup, then we have a classic singleton cleanup problem, as John 
>>> Maddock
>>> pointed out --- the order of static destruction can now be important.
>>
>> You mean an extra non-POD version? That's not your problem... as long
>> as you provide a POD version + call_once_reset/destroy().
>
> So, you're suggesting that we store the result with the once_flag, and 
> then
> leave it up to users to schedule a call to call_once_reset, to ensure the
> result gets cleared up?
>
> Hmm.
>
> I'd still like to know how the user can safely schedule the call to
> call_once_reset, so it doesn't cause problems. I suppose there's an 
> element to
> which it doesn't really matter; the result will just be reinitialized if
> there's a subsequent call_once.
>
> I don't like leaving things as "not my problem", unless I can see that 
> there
> is a safe solution.

Me neither, and I still don't see what having a return value really gains us 
in this case (I would much rather be able to pass parameters to the 
call_once procedure, but that's a whole other ball game).

If a return value is truly required, then we could use aligned_storage to 
provide raw storage for the return value and construct the object on first 
call to the one procedure, but that still doesn't solve the destruction 
problem.

John.