(self, current_time: float)
| 932 | self._timeout = self.io_loop.add_timeout(self._next_timeout, self._run) |
| 933 | |
| 934 | def _update_next(self, current_time: float) -> None: |
| 935 | callback_time_sec = self.callback_time / 1000.0 |
| 936 | if self.jitter: |
| 937 | # apply jitter fraction |
| 938 | callback_time_sec *= 1 + (self.jitter * (random.random() - 0.5)) |
| 939 | if self._next_timeout <= current_time: |
| 940 | # The period should be measured from the start of one call |
| 941 | # to the start of the next. If one call takes too long, |
| 942 | # skip cycles to get back to a multiple of the original |
| 943 | # schedule. |
| 944 | self._next_timeout += ( |
| 945 | math.floor((current_time - self._next_timeout) / callback_time_sec) + 1 |
| 946 | ) * callback_time_sec |
| 947 | else: |
| 948 | # If the clock moved backwards, ensure we advance the next |
| 949 | # timeout instead of recomputing the same value again. |
| 950 | # This may result in long gaps between callbacks if the |
| 951 | # clock jumps backwards by a lot, but the far more common |
| 952 | # scenario is a small NTP adjustment that should just be |
| 953 | # ignored. |
| 954 | # |
| 955 | # Note that on some systems if time.time() runs slower |
| 956 | # than time.monotonic() (most common on windows), we |
| 957 | # effectively experience a small backwards time jump on |
| 958 | # every iteration because PeriodicCallback uses |
| 959 | # time.time() while asyncio schedules callbacks using |
| 960 | # time.monotonic(). |
| 961 | # https://github.com/tornadoweb/tornado/issues/2333 |
| 962 | self._next_timeout += callback_time_sec |
no outgoing calls