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
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.
The text was updated successfully, but these errors were encountered:
Ryanf55
changed the title
uxr_millis() returning 0 causes block in read
Block bug: uxr_millis() returning 0 causes block in read
Mar 4, 2023
Ryanf55
changed the title
Block bug: uxr_millis() returning 0 causes block in read
Block bug: uxr_millis() returning 0 causes block in wait_session_status
Mar 4, 2023
…cking in uxr_create_session
* Added asserts that protect against time going backwards or staying static
* Added information to header on a call being blocking and for how long
* Increased const-correctecness of time handling
* Add assert for handling narrowing conversion of time
* Add CMake protection for incorrectly configuring options that can block for unreasonable amount of time
* CMake should theoretically remove the asserts in release mode, so there should be no overhead
* Reference: https://stackoverflow.com/questions/34302265/does-cmake-build-type-release-imply-dndebug
* CloseseProsima#350
Signed-off-by: Ryan Friedman <[email protected]>
Originally posted by @Ryanf55 in #322 (comment)
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_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.
The text was updated successfully, but these errors were encountered: