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