Lei Liu

> I don't think this completely solves the parameter event batching issue. Since `__declare_parameters_common` calls `__set_parameters_atomically_common` in a loop, even though the parameter events for parameter declaration are batched together,...

@Aposhian > __set_parameters_atomically_common sends parameter events each iteration of the loop. `__set_parameters_atomically_common` does not send parameter events, it just fill parameter info per iteration, the publish work will done once...

@fujitatomoya if we change `declare_parameters/_atomically` return `rcl_interfaces::msg::SetParametersResult`, but the exist APIs bellow: ```c++ template std::vector Node::declare_parameters( const std::string & namespace_, const std::map & parameters, bool ignore_overrides) ``` which return parameter...

@fujitatomoya Sorry, I have reforked `rclcpp` with rolling branch (the old one does not contain it) for new work. I forgot the PR still associated with the old one.

It seems Jenkins broken: ``` 17:21:20 FATAL: command execution failed 17:26:12 java.nio.channels.ClosedChannelException 17:26:12 at org.jenkinsci.remoting.protocol.impl.ChannelApplicationLayer.onReadClosed(ChannelApplicationLayer.java:209) 17:26:12 at org.jenkinsci.remoting.protocol.ApplicationLayer.onRecvClosed(ApplicationLayer.java:221) 17:26:12 at org.jenkinsci.remoting.protocol.ProtocolStack$Ptr.onRecvClosed(ProtocolStack.java:817) 17:26:12 at org.jenkinsci.remoting.protocol.FilterLayer.onRecvClosed(FilterLayer.java:288) ``` Can anybody fix it?

+1 this issue happend very early, see https://answers.ros.org/question/322950/messagepoolmemorystrategy-initialization-fails-with-sensor_msgsmsgimu, I also wonder to known if it is a design limit for memory management?

@fujitatomoya here the basic usage: ```c++ #include #include "rclcpp/wait_for_message.hpp" #include using namespace std::chrono_literals; int main(int argc, char **argv) { // Init ROS rclcpp::init(argc, argv); auto node = std::make_shared("wait_for_message_node"); std_msgs::msg::String out;...

@fujitatomoya > the question was, what if we use already added to an executor node to issue wait_for_message. that is what i am not sure. OK, I'll have a try.

@fujitatomoya > the question was, what if we use already added to an executor node to issue wait_for_message. that is what i am not sure. Create a node for issue...

During my test for zero copy, I found there's only talker_loaned_message, so I add a pair for it, hope it's useful. Thanks.