On 3/28/2012 10:29 AM, Guido van Rossum wrote: > On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> Completely unintuitive and unnecessary. With the GIL taking care of >> synchronisation issues, we can easily coerce time.time() into being a >> monotonic clock by the simple expedient of saving the last returned >> value: > > That's a pretty obvious trick. But why don't the kernels do this if > monotonicity is so important? I'm sure there are also downsides, e.g. > if the clock is accidentally set forward by an hour and then back > again, you wouldn't have a useful clock for an hour. And the cache is > not shared between processes so different processes wouldn't see the > same clock value (I presume that most of these clocks have state in > the kernel that isn't bound to any particular process -- AFAIK only > clock() does that, and only on Unixy systems). >
What makes you think that isn't already true? I don't know what platforms that CPython compiles for that *won't* have one of the aforementioned functions available that provide a *real* monotonic clock. Surely, any platform that doesn't didn't recognize the need for it, or they would just provide a monotonic clock. That is to say, if you are a POSIX compliant system, then there is no reason to break gettimeofday() and friends when you can just implement CLOCK_MONOTONIC proper (even if it's just a trick like Nick's). I think the PEP should enumerate what platforms that CPython supports that will not benefit from a real monotonic clock. I think the number of platforms will be such a minority that the emulation makes sense. Practicality beats purity, and all. -- Scott Dial sc...@scottdial.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
