On Wed, Mar 28, 2012 at 2:36 PM, Scott Dial <scott+python-...@scottdial.com> wrote: > 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?
What does "that" refer to in this sentence? > 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 -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
