This causes invalid underflow when the `uxr_millis()` returns something invalid, such as the embedded device does not have GPS time yet. I could use some info on how this is being used internally if we have to have a time jump (from boot time to RTC time)
When we put Micro-XRCE-DDS-Client on real hardware based on ChibiOS, our time function was returning a time of 0 while the RTC was starting up. It is not clear from the docs what the expectation of one implementing uxr_millis() is in terms of whether that clock needs to always increment, if it's synced up with NTP which allows going backwards whether that is allowed (it's not by the current API), and if clock drift even matters for this function.
Because of this, the uxr_millis() function was having silent underflow, even in debug mode, and blocking forever. Since users are allowed to implement their own uxr_millis functions for custom architectures, it's my opinion the calling code should have some protections to avoid blocking forever.
The PR I created attempts to protect against this in debug mode so developers can fix their clock functions. There may be better approaches, or further clarifications in the docs that will result in a better experience for developers. I tried clarifying what I could in the docs.
_Originally posted by @Ryanf55 in https://github.com/eProsima/Micro-XRCE-DDS-Client/pull/322#discussion_r1125391123_
When we put Micro-XRCE-DDS-Client on real hardware based on ChibiOS, our time function was returning a time of 0 while the RTC was starting up. It is not clear from the docs what the expectation of one implementing
uxr_millis()is in terms of whether that clock needs to always increment, if it's synced up with NTP which allows going backwards whether that is allowed (it's not by the current API), and if clock drift even matters for this function.Because of this, the
uxr_millis()function was having silent underflow, even in debug mode, and blocking forever. Since users are allowed to implement their ownuxr_millisfunctions for custom architectures, it's my opinion the calling code should have some protections to avoid blocking forever.The PR I created attempts to protect against this in debug mode so developers can fix their clock functions. There may be better approaches, or further clarifications in the docs that will result in a better experience for developers. I tried clarifying what I could in the docs.