This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients belopolsky, mark.dickinson, pitrou, rhettinger, tim.peters
Date 2010-07-12.17:06:10
SpamBayes Score 0.0031748877
Marked as misclassified No
Message-id <1278954367.3134.4.camel@localhost.localdomain>
In-reply-to <AANLkTil3mK5cU-yjqSqOuihR8FKZ_DNhUdgVrYtm6_sY@mail.gmail.com>
Content
> > Instead of being defined in _time.h, perhaps the new API function should be provided by core Python?
> 
> This is an interesting idea, but proposed Py_gettimeofday inherits
> float_time logic of falling back on ftime and then plain time in case
> gettimeofday is not available.  I am not sure this behavior is always
> beneficial.

I would say this is fine as long as it's "documented". The whole point
of this API is precisely to avoid having to code the various fallbacks
and conversions by yourself. People wanting full control over the code
path can just write their own routine.

>   I notice that Python/ceval_gil.h has a comment /* We
> assume all modern POSIX systems have gettimeofday() */, which means it
> handles windows completely differently and using   Py_gettimeofday
> instead of GETTIMEOFDAY in gil code may not be appropriate.

Indeed, the GIL code would probably still use its own code paths.
However, other less sensitive code could rely on the new API. For
example, it is not critical for lock timeouts to benefit from the full
gettimeofday() precision.
History
Date User Action Args
2010-07-12 17:06:14pitrousetrecipients: + pitrou, tim.peters, rhettinger, mark.dickinson, belopolsky
2010-07-12 17:06:12pitroulinkissue9079 messages
2010-07-12 17:06:10pitroucreate