Yes, the intended use is relative timings and timeouts. I think we are complicating things far too much. 1) Do we really need a fallback on windows? Will QPC ever fail? 2) is it a problem for the intended use if we cannot absolutely guarantee that time won't ever tick backwards?
IMHO, we shouldn't compilicate the api, and make whatever best try we can in C. On windows I would do this (pseudocode) Static last_time = 0 If (QPC_works) time = QueryPerformanceCounter() else time = GetSystemTimeAsFileTime() if (time > last_time) last_time=time else time = last_time return time in other words: 1) use QPC. If the api indicates that it isn't available (does this ever happen in real life?) use a fallback of system time 2) enforce monotonicity with a static. QPC, if the OS doesn"t is buggy (calls cpu counter rather than timer chip) can cause jitter because it is called on different cores. No options in the api. No nothing. We simply provide the best api possible and some hardware/software combos might be less accurate. K -----Original Message----- From: python-dev-bounces+kristjan=ccpgames....@python.org [mailto:python-dev-bounces+kristjan=ccpgames....@python.org] On Behalf Of Matt Joiner Sent: 14. mars 2012 09:12 To: Antoine Pitrou; Victor Stinner; Guido van Rossum Cc: python-dev@python.org Subject: Re: [Python-Dev] Drop the new time.wallclock() function? I have some observations regarding this: Victor's existing time.monotonic and time.wallclock make use of QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of these are hardware-based counters, their monotonicity is just a convenient property of the timer sources. Furthermore, time values can actually vary depending on the processor the call is served on. time.hardware()? time.monotonic_raw()? There are bug reports on Linux that CLOCK_MONOTONIC isn't always monotonic. This is why CLOCK_MONOTONIC_RAW was created. There's also the issue of time leaps (forward), which also isn't a problem with the latter form. time.monotonic(raw_only=False)? The real value of "monotonic" timers is that they don't leap backwards, and preferably don't leap forwards. Whether they are absolute is of no consequence. I would suggest that the API reflect this, and that more specific time values be obtained using the proper raw syscall wrapper (like time.clock_gettime) if required. time.relative(strict=False)? The ultimate use of the function name being established is for use in timeouts and relative timings. Where an option is present, it disallows fallbacks like CLOCK_MONOTONIC and other weaker forms: * time.hardware(fallback=True) -> reflects the source of the timing impeccably. alerts users to possible affinity issues * time.monotonic_raw() -> a bit linux specific... * time.relative(strict=False) -> matches the use case. a warning could be put regarding hardware timings * time.monotonic(raw_only=False) -> closest to the existing implementation. the keyword name i think is better. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
