Browse Source
Based on the earlier discussed RFC. Practice showed that the most natural order for arguments corresponds to mathematical subtraction: ticks_diff(x, y) <=> x - y Also, practice showed that in real life, it's hard to order events by time of occurance a priori, events tend to miss deadlines, etc. and the expected order breaks. And then there's a need to detect such cases. And ticks_diff can be used exactly for this purpose, if it returns a signed, instead of unsigned, value. E.g. if x is scheduled time for event, and y is the current time, then if ticks_diff(x, y) < 0 then event has missed a deadline (and e.g. needs to executed ASAP or skipped). Returning in this case a large unsigned number (like ticks_diff behaved previously) doesn't make sense, and such "large unsigned number" can't be reliably detected per our definition of ticks_* function (we don't expose to user level maximum value, it can be anything, relatively small or relatively large).pull/2577/head
Paul Sokolovsky
8 years ago
1 changed files with 2 additions and 2 deletions
Loading…
Reference in new issue