Open tongtybj opened 4 years ago
Hi, nice PR!
I have never needed a service server on the rosserial_client
side but it is nice to see this feature added.
About the async spinner, from what I understand, the current implementation is using the io_service to keep only one thread to simplify the design and avoid synchronization issues. In your implementation, there is now 3 threads and I do not see any synchronization primitives to protect the resources.
@romainreignier
In your implementation, there is now 3 threads and I do not see any synchronization primitives to protect the resources.
I think the only shared resource that should be protected is the write (async_write
) process, since the ros callback functions and several dealine_timers do the write process from different threads.
So I add a mutex to lock the following part:
Use
topic_tools::ShapeShifter
to createproxy
service servers in rosserial server.Also, during the implementation, I found a very interesting phenomenon. When the callback function of a
proxy
service server is called, all process related toboost::asio
seem to be paused, meaning that no response can be caught from rosserial client unless this service callback function is over. This can be check in c32952f .So I replace
boost::asio::deadline_timer ros_spin_timer_
withros::AsyncSpinner
which has 2 threads. I know this might be a trivial reverting action. But can anyone tell me the motivation to useboost::asio::deadline_timer ros_spin_timer_
and what this comment means?