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
> it
> works. And it doesn't suffer from the rollover issue and the stability
> issues
> that the QPC stuff does in the face of multi-threading. So it just works
> and
> 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
> as
> 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
> to
> store data to handle rollover. QPC based implementation been discussed
> for
> years, but I've never seen anyone actually implement something that works
> as
> 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.
Philippe