>> Impact: A timeout may be 42 seconds shorter than the requested >> duration if is uses QPC. For a scheduler, a task would be scheduled at >> the right moment. > > I don't understand this paragraph. And why is it always exactly a loss > of 42 seconds?
Sorry, it's late here, I'm too tired. A jump of 42 seconds is one of QPC known bug (it was a bug in VirtualBox and it is now fixed). > So is it worth having two functions that are only different on > Windows? ISTM that the average non-Windows user will have a 50% chance > of picking the wrong timer from a portability perspective. Can we solve this by documenting correctly time.highres() issues (it's not really monotonic) and when you need to use time.monotonic() or time.highres()? Well, there is already time.clock() that uses QPC on Windows, but time.highres() and time.clock() give different results for an idle process on UNIX. pybench, timeit and other programs have their own heuristic getting the most accurate clock depending on the OS and on which clocks are available. time.highres() is a portable function for these programs. >> See Zooko Wilcox-O'Hearn's email: >> http://mail.python.org/pipermail/python-dev/2012-March/118147.html > > He explains the basic difference between the two types of clocks, and > that's important. He doesn't say anything about a strict requirement > for monotonicity or steadiness. This is why I still balk at > "monotonic" for the name -- I don't think that monotonicity is the > most important property. But I don't know how the put the desired > requirement in words; "steady" seems to come closer for sure. If we provide a way to check if the monotonic clock is monotonic (or not), I agree to drop the flag from time.monotonic(fallback=True) and always fallback. I was never a fan of the "truly monotonic clock". time.clock_info('monotonic')['is_monotonic'] is a good candidate to store this information. "time.clock_info('monotonic')['is_monotonic']" looks like a bug: why would I check if a *monotonic* clock is *monotonic*? time.clock_info('steady')['monotonic'] looks more natural, but I don't remember why we should not use the term "steady". >> Well, the PEP mentions something like that in the "One function, no >> flag" section. > > But you don't seem to like it. (In general the alternatives section > could do with reasons for rejection or at least pros and cons for each > alternative.) I was concerned by the fact that time.monotonic() may become not-monotonic between two calls, but I changed my mind. I agree that it should not occur in practice. So always fallback and add a way to know if the monotonic clock is monotonic now sounds like the best API to me. Victor _______________________________________________ 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
