From: Philippe Vaucher (philippe.vaucher_at_[hidden])
Date: 2006-11-01 05:32:23
> Sorry to be so quiet...it's not that I'm not interested, just too busy to
> really contribute. Anyway, the reason for GetSystemTimeAsFileTime is that
> works. And it doesn't suffer from the rollover issue and the stability
> that the QPC stuff does in the face of multi-threading. So it just works
> it gives enough precision for 90% of the applications.
I somehow guessed that answer, and I think I agree with it. Personnaly I'm
for letting it as it is, and more or less let my code as it is, that means
that people will use microsec_timer that uses microsec_clock for robust &
good quality code. If they really want more precision, they can use
qpc_timer, which will be documented so people know the issues about it. What
do you think of this guideline ?
> I'll be happy to replace the current microsec_clock implementation as long
> you can deal with rollover and multi-threading. Oh, and you can't add any
> data members to the ptime which might expand it's size. And since the
> microsec_clock is all static there could be some complications if you need
> store data to handle rollover. QPC based implementation been discussed
> years, but I've never seen anyone actually implement something that works
> reliably as GetSystemTimeAsFileTime....
Well with all the conditions and what I know from QPC, it looks like an
unpossible challenge, and if I succeed it's likely that the overhead will be
huge. I think I'll just go with the "convenience" solution where I offer to
already do the SetThreadAffinityMask calls for the users if he wants to etc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk