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