Undesirable behaviour of z_clock_announce() when ticks argument is greater by 1

[pizi-nordic]

The z_clock_announce() unconditionally adjust dticks of first timeout in the list:

if (first() != NULL) {
	first()->dticks -= announce_remaining;
}

However this adjustment is not always valid:

1. If the adjusted timeout was on the list before call to z_clock_announce(), we have to do such correction in order to not delay next timeout.

2. If the adjusted timeout belongs to periodic k_timer which was handled during current z_clock_announce() execution, we should do such correction if we would like to not accumulate error.

3. If the adjusted timeout was added during current z_clock_announce() execution but it is not related periodic timer which was handled, we have to skip the adjustment. If we perform it, the newly scheduled timeout will fire earlier than expected.

This issue has been initially mentioned in #11722.
Affected use case is presented here: #12247 (comment)

[pizi-nordic]

@andyross, @pabigot, @carlescufi: FYI

[andyross]

@pizi-nordic, this is getting out of hand. Not. A. Bug. I don't know how else to explain it. Existing tests require the behavior as implemented. What you are worrying about is an untested edge case that results from an an API convention issue and happens only in latency crisis situations where interrupts have been delayed more than a tick.

It can be fixed via API (and worked around right now), but it requires design and ideas and discussion. I tried to isolate that discussion in #12247. But now it's leaked out as a "bug" and I genuinely don't know what to do.

If you have code that actually fails and has no workaround, submit it as a test first and then submit the bug. But for now... I just don't know how else to deal with this. Stop this senseless argument. Please do not resubmit this without an exercising test case (and not a whiteboxed one!)

[pabigot]

We need consensus on whether this is a bug, since @pizi-nordic and I disagree with your assessment. If it is a bug, it may very well require API and other changes to resolve. That's fine, and not a motivation for closing it until we have consensus.

[andyross]

(And yes, I know you think you understand this better and that I'm missing something important. But without a failing test case it's not a bug, and I'm tired of typing about it)

[andyross]

Without a failing test case, it's not a bug. Please stop this senseless fight. There's a perfectly good discussion elsewhere.