On 2019-11-15 12:11:31 +0100, R.Wieser wrote: > Dennis, > > No, that addition is a fixed increment on the initial starting > > time, and is NOT relative to the ending of a sleep. > > > No, that addition is a fixed increment > > Yep. > > > on the initial starting time > > Nope. > > If pythons sleep is worth its salt it ends exactly on the time provided in > "t".
No. There are many reasons why sleep() might return after t (If I wanted
to be picky, I'd point out that sleep() will never end *exactly* at t,
but let's read "exactly" as "so close it doesn't make a difference").
Very few of those reasons have anything to do with Python: They may be
inherent in the OS (which simply doesn't guarantee that and may not be
able to switch to any process at any time) to the hardware (there may
not be a timer with sufficient resolution, or the interrupt may be
masked, and of course there are context-switch times) to the state of
the system (the system may be busy with a higher priority task, or the
page of your program may not be in RAM and have to be read from disk
first), etc.
> Thus the subsequent addition to that "t" is releative to the end of
> the sleep just before it.
No, because you get the actual time at some time between the the
previous and the next sleep and use that to compute how long to sleep.
So even if sleep() always returned at exactly the intended time, the
time used to compute the sleep time would be a little later. But of
course sleep is never that punctual, but that doesn't matter since that
just adds to that "a little later".
hp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | h...@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list
