PEP 418: Stephen J. Turnbull's patch: typos
This commit is contained in:
Victor Stinner
parent
d0166c382d
commit
9137ddbec3
50
pep-0418.txt
50
pep-0418.txt
|
|
@ -49,7 +49,7 @@ Each operating system implements clocks and performance counters
|
|||
differently, and it is useful to know exactly which function is used
|
||||
and some properties of the clock like its resolution and its
|
||||
precision. The new ``time.get_clock_info()`` function gives access to
|
||||
all available information of each Python time function.
|
||||
all available information about each Python time function.
|
||||
|
||||
New functions:
|
||||
|
||||
|
|
@ -141,7 +141,7 @@ consecutive calls is valid and is a number of seconds.
|
|||
|
||||
On Windows versions older than Vista, ``time.monotonic()`` detects
|
||||
``GetTickCount()`` integer overflow (32 bits, roll-over after 49.7
|
||||
days): it increases a delta by 2\ :sup:`32` each time than an overflow
|
||||
days): it increases a delta by 2\ :sup:`32` each time that an overflow
|
||||
is detected. The delta is stored in the process-local state and so
|
||||
the value of ``time.monotonic()`` may be different in two Python
|
||||
processes running for more than 49 days. On more recent versions of
|
||||
|
|
@ -432,7 +432,7 @@ Other names for time.monotonic()
|
|||
point.
|
||||
|
||||
The name "time.try_monotonic()" was also proposed for an older
|
||||
proposition of time.monotonic() which was falling back to the system
|
||||
version of time.monotonic() which would fall back to the system
|
||||
time when no monotonic clock was available.
|
||||
|
||||
Other names for time.perf_counter()
|
||||
|
|
@ -461,11 +461,11 @@ system time.
|
|||
|
||||
Issues:
|
||||
|
||||
* It is hard to define correctly such function in the documentation:
|
||||
* It is hard to define such a function correctly in the documentation:
|
||||
is it monotonic? Is it steady? Is it adjusted?
|
||||
* Some user want to decide what to do when no monotonic clock is
|
||||
* Some users want to decide what to do when no monotonic clock is
|
||||
available: use another clock, display an error, or do something
|
||||
else?
|
||||
else.
|
||||
|
||||
Different APIs were proposed to define such function.
|
||||
|
||||
|
|
@ -499,7 +499,7 @@ the first call to time.monotonic().
|
|||
Choosing the clock from a list of constraints
|
||||
---------------------------------------------
|
||||
|
||||
The PEP as proposed offers a few new clocks, but their guarentees
|
||||
The PEP as proposed offers a few new clocks, but their guarantees
|
||||
are deliberately loose in order to offer useful clocks on different
|
||||
platforms. This inherently embeds policy in the calls, and the
|
||||
caller must thus choose a policy.
|
||||
|
|
@ -516,7 +516,7 @@ evaluate their suitability.
|
|||
|
||||
The primary interface is a function make simple choices easy:
|
||||
the caller can use ``time.get_clock(*flags)`` with some combination of flags.
|
||||
This include at least:
|
||||
This includes at least:
|
||||
|
||||
* time.MONOTONIC: clock cannot go backward
|
||||
* time.STEADY: clock rate is steady
|
||||
|
|
@ -536,7 +536,7 @@ be chained using the or operator. Example of a simple policy decision::
|
|||
The available clocks always at least include a wrapper for ``time.time()``,
|
||||
so a final call with no flags can always be used to obtain a working clock.
|
||||
|
||||
Example of flags of system clocks:
|
||||
Examples of flags of system clocks:
|
||||
|
||||
* QueryPerformanceCounter: MONOTONIC | HIGHRES
|
||||
* GetTickCount: MONOTONIC | STEADY
|
||||
|
|
@ -606,7 +606,7 @@ Glossary
|
|||
|
||||
:Clock:
|
||||
An instrument for measuring time. Different clocks have different
|
||||
characteristics; for example, a clock with <nanonsecond>
|
||||
characteristics; for example, a clock with <nanosecond>
|
||||
<precision> may start to <drift> after a few minutes, while a less
|
||||
precise clock remained accurate for days. This PEP is primarily
|
||||
concerned with clocks which use a unit of seconds.
|
||||
|
|
@ -723,7 +723,7 @@ List of hardware clocks
|
|||
* TSC (Time Stamp Counter): Historically, the TSC increased with every
|
||||
internal processor clock cycle, but now the rate is usually constant
|
||||
(even if the processor changes frequency) and usually equals the
|
||||
maximum processor frequency. Multiple cores having different TSC
|
||||
maximum processor frequency. Multiple cores have different TSC
|
||||
values. Hibernation of system will reset TSC value. The RDTSC
|
||||
instruction can be used to read this counter. CPU frequency scaling
|
||||
for power saving.
|
||||
|
|
@ -734,10 +734,10 @@ List of hardware clocks
|
|||
IBM "Summit" series chipsets (ex: x440). This is available in IA32
|
||||
and IA64 architectures.
|
||||
* PIT (programmable interrupt timer): Intel 8253/8254 chipsets with a
|
||||
configurable frequency in range 18.2 Hz - 1.2 MHz. It is a 16-bit
|
||||
configurable frequency in range 18.2 Hz - 1.2 MHz. It uses a 16-bit
|
||||
counter.
|
||||
* RTC (Real-time clock). Most RTCs use a crystal oscillator with a
|
||||
frequency of 32,768 Hz
|
||||
frequency of 32,768 Hz.
|
||||
|
||||
|
||||
Linux clocksource
|
||||
|
|
@ -747,7 +747,7 @@ There were 4 implementations of the time in the Linux kernel: UTIME
|
|||
(1996), timer wheel (1997), HRT (2001) and hrtimers (2007). The
|
||||
latter is the result of the "high-res-timers" project started by
|
||||
George Anzinger in 2001, with contributions by Thomas Gleixner and
|
||||
Douglas Niehaus. hrtimers implementation was merged into Linux
|
||||
Douglas Niehaus. The hrtimers implementation was merged into Linux
|
||||
2.6.21, released in 2007.
|
||||
|
||||
hrtimers supports various clock sources. It sets a priority to each
|
||||
|
|
@ -782,7 +782,7 @@ Read also the `time(7) manual page
|
|||
FreeBSD timecounter
|
||||
-------------------
|
||||
|
||||
kern.timecounter.choice list available hardware clocks with their
|
||||
kern.timecounter.choice lists available hardware clocks with their
|
||||
priority. The sysctl program can be used to change the timecounter.
|
||||
Example::
|
||||
|
||||
|
|
@ -819,7 +819,7 @@ Read `Timecounters: Efficient and precise timekeeping in SMP kernels
|
|||
Performance
|
||||
-----------
|
||||
|
||||
Reading an hardware clock has a cost. The following table compares
|
||||
Reading a hardware clock has a cost. The following table compares
|
||||
the performance of different hardware clocks on Linux 3.3 with Intel
|
||||
Core i7-2600 at 3.40GHz (8 cores). The `bench_time.c
|
||||
<http://hg.python.org/peps/file/tip/pep-0418/bench_time.c>`_ program
|
||||
|
|
@ -864,7 +864,7 @@ CLOCK_MONOTONIC 201 ns 10766 ns 4498 ns 3943 ns
|
|||
======================== ====== ========= ======= =======
|
||||
|
||||
Each function was called 100,000 times and CLOCK_MONOTONIC was used to
|
||||
get the time before and after. The benchmark was run 5 times to keep
|
||||
get the time before and after. The benchmark was run 5 times, keeping
|
||||
the minimum time.
|
||||
|
||||
|
||||
|
|
@ -881,14 +881,14 @@ NTP has different methods to adjust a clock:
|
|||
* "stepping": jump by a large amount in a single discrete step (which
|
||||
is done with ``settimeofday()``)
|
||||
|
||||
By default, the time is slewed if the offset is less than 128 ms, or
|
||||
By default, the time is slewed if the offset is less than 128 ms, but
|
||||
stepped otherwise.
|
||||
|
||||
Slewing is generally desirable (i.e. we should use CLOCK_MONOTONIC,
|
||||
not CLOCK_MONOTONIC_RAW) if one wishes to measure "real" time (and not
|
||||
a time-like object like CPU cycles). This is because the clock on the
|
||||
other end of the NTP connection from you is probably better at keeping
|
||||
time: hopefully that thirty five thousand dollars of Cesium
|
||||
time: hopefully that thirty-five thousand dollars of Cesium
|
||||
timekeeping goodness is doing something better than your PC's $3
|
||||
quartz crystal, after all.
|
||||
|
||||
|
|
@ -1223,7 +1223,7 @@ to CLOCK_REALTIME, less precise but faster.
|
|||
Alexander Shishkin proposed an API for Linux to be notified when the system
|
||||
clock is changed: `timerfd: add TFD_NOTIFY_CLOCK_SET to watch for clock changes
|
||||
<http://lwn.net/Articles/432395/>`_ (4th version of the API, March 2011). The
|
||||
API is not accepted yet, CLOCK_BOOTTIME provides a similar feature.
|
||||
API is not accepted yet, but CLOCK_BOOTTIME provides a similar feature.
|
||||
|
||||
|
||||
Process Time
|
||||
|
|
@ -1291,7 +1291,7 @@ Functions
|
|||
program.
|
||||
|
||||
* getrusage(RUSAGE_SELF) returns a structure of resource usage of the currenet
|
||||
process. ru_utime is use CPU time and ru_stime is the system CPU time.
|
||||
process. ru_utime is user CPU time and ru_stime is the system CPU time.
|
||||
* times(): structure of process times. The precision is 1 / ticks_per_seconds,
|
||||
where ticks_per_seconds is sysconf(_SC_CLK_TCK) or the HZ constant.
|
||||
|
||||
|
|
@ -1466,11 +1466,11 @@ Other functions
|
|||
System Standby
|
||||
==============
|
||||
|
||||
The ACPI power state "S3" is as system standby mode, also called
|
||||
The ACPI power state "S3" is a system standby mode, also called
|
||||
"Suspend to RAM". RAM remains powered.
|
||||
|
||||
On Windows, the ``WM_POWERBROADCAST`` message is send to Windows
|
||||
application to notify them of power-management events (ex: ower status
|
||||
On Windows, the ``WM_POWERBROADCAST`` message is sent to Windows
|
||||
applications to notify them of power-management events (ex: owner status
|
||||
has changed).
|
||||
|
||||
For Mac OS X, read `Registering and unregistering for sleep and wake
|
||||
|
|
@ -1484,7 +1484,7 @@ Footnotes
|
|||
|
||||
.. [#pseudo] "_time" is an hypothetical module only used for the example.
|
||||
The time module is implemented in C and so there is no need for
|
||||
such module.
|
||||
such a module.
|
||||
|
||||
|
||||
Links
|
||||
|
|
|
|||
Loading…
Reference in New Issue