Current model is to have two threads…
A signal detector (actionlib client read())
and a signal handler (state machine with actionlib client write())
How should multiple threads be used?
The text in block quotes below comes from.. https://www.amazon.com/Linux-Programming-Interface-System-Handbook-ebook/dp/B004OEJMZM
The Linux Programming Interface Book has mentioned a method for dealing with asynchronous signals in a multi threaded program. See pg 685, section 33.2.4 …
In Chapters 20 to 22, we discussed various factors-such as redundancy issues, the need to restart interrupted system calls, and avoiding race conditions-that can make it complex to deal with asynchronously generated signals via signal handlers. Furthermore, none of the functions in the Pthreads API is among the set of async-signal-safe functions that we can safely call from within a signal handler. For these reasons, multithreaded programs that must deal with asynchronously generated signals should generally not use a signal handler as the mechanism to receive notification of signal delivery. Instead, the preferred approach is the following…
- All threads block all of the asynchronous signals that the process might receive. The simplest way to do this is to block the signals in the main thread before any other thread are created. Each subsequently created thread will inherit a copy of the main thread’s signal mask.
- Create a single dedicated thread that accepts incoming signals using sigwaitinfo(), sigtimedwait() or sigwait().
The advantage of this approach is that asynchronously generated signals are received synchronously. As it accepts incoming signals, the dedicated thread can safely modify shared variables (under mutex control) and call non-async-signal-safe functions. It can also signal condition variables, and employ other thread and process communication and synchronization mechanisms.
ROS Asynch Spinner (from roscpp spinner.cpp) uses boost/threads
So does Boost Statechart. So we should be ok.
Actionlib’s threading capabilities…
Andreas Huber discussing the fifo_scheduler…
ROS Master Threading Model (roscpp)…
See Page __ of Ingo Lutkenbohle’s “Determinism in Robotics” presentation at ROSCON 2017