A v1 periodic activity that significantly misses a deadline, races to catch up by cycling the task as fast as possible until all the deadlines that have been missed have been caught up. Not what was expected ...

We have a hardware device who's RTT component runs at 500 Hz. But with certain state changes, the device can block for over 0.5 seconds (don't ask me!). When this happens to us, we get the long 0.5 second pause, and then the RTT component attempts to catch up by running at ~6 kHz until it's made up all those missed deadlines. Yuck!

I see this is fixed in v2 (in almost the exact same manner we fixed it in v1), though I'm not quite sure where the user can set the wait_policy. Would it be acceptable for us to provide a patch that backported the fix in just rtos_task_wait_period(), that is perhaps based on a global compiled-in policy (set as a CMake ORO_xxx variable)? The default policy would be the current behaviour.
S