Incoherent delay handling in the clock
I've started writing tests for the clock.c
code to fix #27918. I've started to build some simple case to get the hand on it (assigning mainly master and not the slave for now), but stumbled upon a weird incoherency on the delay handling. The setup is one master clock and two slaves clocks.
Setting clock master delay to 1000
- clock master has delay 1000
- clock slave1 has delay 0
- clock slave2 has delay 0
Setting clock master delay to -1000
- clock master has delay 1000
- clock slave1 has delay 2000
- clock slave2 has delay 2000
Setting clock master delay to 1000
- clock master has delay 1000
- clock slave1 has delay 0
- clock slave2 has delay 0
This is displaying the delay as clock->delay
for master and clock->delay - main_clock->delay
for slaves.
From what I understand, the delay could be always incremented like in the second assignment of clock master delay to ensure we have a causal behaviour, though I'd rather handle it at a clock context level like Thomas suggested and developed, since it provides much better control on what is differed and how the core will handle the delay.
However, it should then not reset to the initial state in the second situation. Which means that clock delays in the third assignment should be
Setting clock master delay to 1000
- clock master has delay 3000
- clock slave1 has delay 2000
- clock slave2 has delay 2000
Otherwise, clock delays for the second assignment should be
Setting clock master delay to -1000
- clock master has delay 0
- clock slave1 has delay 1000
- clock slave2 has delay 1000
I open the ticket because I'm unsure which variant will be accepted on MR.