iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 418: Cleanup the glossary 

* <nanosecond> and <clock_monotonic> are not terms of the glossary
 * remove the useless definition of duration
 * monotonic: reading a monotonic clock is not slower than other clock
This commit is contained in:
Victor Stinner 2012-04-28 10:59:31 +02:00
parent 7cbdcfa301
commit 92e2f078f0
1 changed files with 3 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
pep-0418.txt
View File

@ -610,14 +610,14 @@ Glossary
:Clock:
An instrument for measuring time. Different clocks have different
characteristics; for example, a clock with <nanosecond>
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.
:Counter:
A clock which increments each time a certain event occurs. A
counter is <strictly monotonic>, but not <clock_monotonic>. It can
counter is strictly monotonic, but not a monotonic clock. It can
be used to generate a unique (and ordered) timestamp, but these
timestamps cannot be mapped to <civil time>; tick creation may well
be bursty, with several advances in the same millisecond followed
@ -630,12 +630,6 @@ Glossary
when profiling, but they do not map directly to user response time,
nor are they directly comparable to (real time) seconds.
:Duration:
Elapsed time. The difference between the starting and ending
times. A defined <epoch> creates an implicit (and usually large)
duration. More precision can generally be provided for a
relatively small <duration>.
:Drift:
The accumulated error against "true" time, as defined externally to
the system. Drift may be due to imprecision, or to a difference
@ -657,12 +651,7 @@ Glossary
Moving in at most one direction; for clocks, that direction is
forward. The <clock> should also be <steady>, and should be
convertible to a unit of seconds. The tradeoffs often include lack
of a defined <epoch> or mapping to <Civil Time>, and being more
expensive (in <latency>, power usage, or <duration> spent within
calls to the clock itself) to use. For example, the clock may
represent (a constant multiplied by) ticks of a specific quartz
timer on a specific CPU core, and calls would therefore require
synchronization between cores.
of a defined <epoch> or mapping to <Civil Time>.
:Precision:
The amount of deviation among measurements of the same physical