Passing 0 or even negative numbers to the final rcl_wait is well defined and there is no reason to impose any limitation in this wrapper code, that I know of.
The unit of timeout is nanoseconds. If the timeout is negative then this function will block indefinitely until something in the wait set is valid or it is interrupted. If the timeout is 0 then this function will be non-blocking; checking what's ready now, but not waiting if nothing is ready yet. If the timeout is greater than 0 then this function will return after that period of time has elapsed or the wait set becomes ready, which ever comes first.
Passing 0 or even negative numbers to the final rcl_wait is well defined and there is no reason to impose any limitation in this wrapper code, that I know of.
See: https://docs.ros2.org/beta1/api/rcl/wait_8h.html#a732278988c802fe2c9d8ec24752f9dd9
The unit of timeout is nanoseconds. If the timeout is negative then this function will block indefinitely until something in the wait set is valid or it is interrupted. If the timeout is 0 then this function will be non-blocking; checking what's ready now, but not waiting if nothing is ready yet. If the timeout is greater than 0 then this function will return after that period of time has elapsed or the wait set becomes ready, which ever comes first.
My suggestion is to simply pull: https://github.com/RobotecAI/ros2cs/pull/16 which removes the lower-bound checking of timeoutSec in spinOnce.
This has been tested and we noticed a big performance boost when running in a high-frequency application.