You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes an issue with time discrepancies that stopped the reaction cycle if the operator was unlucky enough to hit the scheduled awakening time with 1ms precision.
Description
Previously, "now" of handler.awakened and "now" of state.delay were different (maybe for less than 1 ms). If the scheduled awakening time was unlucky to be between these two points in time, the operator stopped reacting on this object until any other events or changes arrive.
Specifically, the operator neither selected the handlers to be executed (because it was "1ms too early" for the handler.awakened), nor did it sleep (because it was "1ms too late" in the state.delay property) — with the same value of delayed field, just the code being executed exactly during this awakening time.
Due to how zero-time delay is treated (i.e. same as None — no sleep at all), the dummy patch was not applied to trigger the next steps of the reaction cycle.
After the fix, 0-delay and None-delay are treated differently: the zero-time delay does not sleep, but produces a dummy patch to trigger the reaction cycle after the sleep is over (as if it was an actual zero-time sleep). The None delay does not do any sleeping or dummy patching.
This eliminates the problem with the "now" time inconsistencies, while keeps the multiple datetime.datetime.utcnow() possible — to properly calculate the needed sleep time without the code overhead included.
The change does not affect the users directly. The probability of hitting this issue was low anyway.
What do these changes do?
Fixes an issue with time discrepancies that stopped the reaction cycle if the operator was unlucky enough to hit the scheduled awakening time with 1ms precision.
Description
Previously, "now" of
handler.awakened
and "now" ofstate.delay
were different (maybe for less than 1 ms). If the scheduled awakening time was unlucky to be between these two points in time, the operator stopped reacting on this object until any other events or changes arrive.Specifically, the operator neither selected the handlers to be executed (because it was "1ms too early" for the
handler.awakened
), nor did it sleep (because it was "1ms too late" in thestate.delay
property) — with the same value ofdelayed
field, just the code being executed exactly during this awakening time.Due to how zero-time delay is treated (i.e. same as
None
— no sleep at all), the dummy patch was not applied to trigger the next steps of the reaction cycle.After the fix,
0
-delay andNone
-delay are treated differently: the zero-time delay does not sleep, but produces a dummy patch to trigger the reaction cycle after the sleep is over (as if it was an actual zero-time sleep). TheNone
delay does not do any sleeping or dummy patching.This eliminates the problem with the "now" time inconsistencies, while keeps the multiple
datetime.datetime.utcnow()
possible — to properly calculate the needed sleep time without the code overhead included.The change does not affect the users directly. The probability of hitting this issue was low anyway.
Issues/PRs
Type of changes
Checklist
CONTRIBUTORS.txt
The text was updated successfully, but these errors were encountered: