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 belopolsky
Recipients belopolsky, mark.dickinson, pitrou, rhettinger, tim.peters
Date 2010-07-12.17:16:43
SpamBayes Score 0.0027206987
Marked as misclassified No
Message-id <AANLkTikkLqs29pQj37obudTgWVP5k7bDVahbCEzagHsB@mail.gmail.com>
In-reply-to <1278954367.3134.4.camel@localhost.localdomain>
Content
On Mon, Jul 12, 2010 at 1:06 PM, Antoine Pitrou <report@bugs.python.org> wrote:
..
> 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.

That may be true, but I would rather proceed in small steps.  First
expose it in _time.h so that it is shared by time and datetime
modulesand then if specific uses are found inside core python, move it
to a more appropriate header.   Lock timeouts are not a good use case
for gettimeofday because POSIX APIs use nonoseconds instead of
microseconds.
History
Date User Action Args
2010-07-12 17:16:45belopolskysetrecipients: + belopolsky, tim.peters, rhettinger, mark.dickinson, pitrou
2010-07-12 17:16:43belopolskylinkissue9079 messages
2010-07-12 17:16:43belopolskycreate