On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
> <victor.stin...@gmail.com> wrote:
>>>>> In that case, I don't think time.try_monotonic() is really needed
>>>>> because we can emulate "time.monotonic()" in software if the platform is
>>>>> deficient.
>>>>
>>>> As I wrote, I don't think that Python should workaround OS bugs. If
>>>> the OS monotonic clock is not monotonic, the OS should be fixed.
>>>
>>> I sympathize with this, but if the idea is that the Python stdlib should
>>> use time.monotonic() for scheduling, then it needs to always be
>>> available. Otherwise, we are not going to use it ourselves, and what
>>> sort of example is that to set?
>>
>> There is time.hires() if you need a monotonic clock with a fallback to
>> the system clock.
>
> 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:
>
>  def _make_monotic:
>      try:
>          # Use underlying system monotonic clock if we can
>          return _monotonic
>      except NameError:
>          _tick = time()
>          def monotic():
>              _new_tick = time()
>              if _new_tick > _tick:
>                  _tick = _new_tick
>              return _tick
>
>  monotonic = _make_monotonic()
>
> Monotonicity of the result is thus ensured, even when using
> time.time() as a fallback.
>
> If using the system monotonic clock to get greater precision is
> acceptable for an application, then forcing monotonicity shouldn't be
> a problem either.

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).

-- 
--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

Reply via email to