On 2019-11-19 08:57:23 +0100, R.Wieser wrote: > First things first: For some reason I see your message coming in empty, but > with two attachments. An "att*.txt" one with the actual message contents, > and a "signature.asc". Makes it kind of hard to read ...
You seem to be using MS Outlook Express 6.0. That program was never
known for great standards conformance and has been discontinued by MS 11
years ago.
> > No. There are many reasons why sleep() might return after t
>
> Not /that/ many, but true. But do you think that adding all of those
> if-when-but reasons to the issue I tried to explain would be a good idea ?
It does when it determines whether your program is correct or not.
> I don't.
Well, then don't. But then don't complain that your programs don't work
as expected either.
> > No, because you get the actual time at some time between the the
> > previous and the next sleep
>
> No, you don't. Thats the whole trick. The only place where you ask for the
> time (and subtract it from the desired one) is directly infront of actually
> doing the sleep.
You were talking about the end of the previous sleep, not the start of
the next one in your previous message, but it doesn't matter. The call
to perf_counter still happens at some time between the previous and the
next sleep. Here is a disassembly of the line
time.sleep(timeInterval - (time.perf_counter() % timeInterval))
:
10 8 LOAD_GLOBAL 1 (time)
10 LOAD_METHOD 2 (sleep)
12 LOAD_GLOBAL 3 (timeInterval)
14 LOAD_GLOBAL 1 (time)
16 LOAD_METHOD 4 (perf_counter)
18 CALL_METHOD 0
20 LOAD_GLOBAL 3 (timeInterval)
22 BINARY_MODULO
24 BINARY_SUBTRACT
26 CALL_METHOD 1
28 POP_TOP
So there are three instructions between the return of perf_counter and
the call to sleep: LOAD_GLOBAL, BINARY_MODULO and BINARY_SUBTRACT. They
shouldn't take much time, but they do take time.
> (dotting i's works two ways I'm afraid :-) ). And the
> /asked for/ time (before subtraction of the current time I mean - ghah! I
> hate needing to specify every fricking detail) will be exactly the specified
> increment away from the (calculated!) last one. And yes, that thus also
> tries to negate a previous sleep having ended late.
>
> In short: The calculated(!) next sleeps termination time is not dependant on
> how well the previous sleeps and code between them behaved.
Correct. That's the intention of this code. From your previous postings
it wasn't apparent that you had understood this. In fact you seemed to
be arguing that this either wasn't necessary or couldn't possibly be
working.
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
