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.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
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
