Michael Carroll

[Holding for Iron sync](https://discourse.ros.org/t/preparing-for-iron-sync-2024-09-06/) If you want these in faster, it's better to separate them. Otherwise we will wait until there are no sync holds for the impacted distros.

Friendly ping @puck-fzi you should be able to get these PRs unblocked now that you have the ros2-gbp repos available.

I notice that there is not a `package.xml` in this package. How is expected that this software is built and packaged? Are you intending to introduce a vendor package?

> i would like to hear from RTI developer for this behavior. @asorbini any chance that you or someone else from the RTI team may be able to shed some...

Can you re-profile with the callback groups set to `Reentrant`? While I don't think that the timing looks correct here, using purely mutually exclusive callback groups with multithreaded executor is...

> I think it is not unreasonable for a user to want to use a MultiThreadedExecutor with MutuallyExclusive when he has several nodes, to parallelize both. In this case, each...

> I understand that you don't consider this a problem if the user knows it can suffer starvation and actively do something to avoid it. I do think it's probably...

Yes, there is a cost to the bookkeeping that the multithreaded executor requires. Perhaps it can continue to be made better (that overhead can be reduced), but there is always...

I believe that we determined that even the single threaded executor can be starved with high enough frequency timer updates https://github.com/ros2/rclcpp/issues/392

> There is probably a better implementation, but the idea seems to work. We had previously discussed having the execution order of ready entities be managed by some sort of...