On 04/05/2010 08:56 AM, Bruno Haible wrote: > Hi Eric, > >>> - QueryPerformanceCounter [1] has a resolution of 0.5 ms or higher. >> >> ... if you use it, then you run into the issues of file timestamp mismatch >> (cygwin currently has a known issue where, because it uses >> QueryPerformanceCounter instead of GetSystemTimeAsFileTime for >> implementing utimensat(UTIME_NOW), a file can not only appear newer than >> what a corresponding file system operation would be, but also time can >> appear to travel backwards when following a utimensat(UTIME_NOW) >> operation by a normal file system operation). > > This matches the difficulties that are described in [1]. But I would think > the difficulties come in only when you try to combine the > GetSystemTimeAsFileTime and QueryPerformanceCounter results? When you use > only QueryPerformanceCounter, you should be fine (except for [2])?
As I see it, using QueryPerformanceCounter in isolation is fine; the problems only come when you try to correlate between two different counters of two different resolutions. So if all you are trying to do is measure elapsed time, rather than setting timestamps of files that will match the system's notion of file timestamps, I don't think we are running into obvious problems. It's just that it is always worth an extra bit of caution when dealing with subsecond resolutions, because the ramifications are not always immediately apparant. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
