That doesn't matter. The thing that matters is where they originate from and that seems to be the thread object which lives in the main thread.
Which is currently handled by the main thread as well.Except for one, which is the signal that carries the joint angles from the KeyframePlayer thread to the RobotInterface thread.
I mean you should have an event loop there in the first place. And when you do, push the thread object to its thread so that it can handle its signals and slots properly.So the point you are trying to make is that I should actually queue this one signal and handle it in the RobotInterface's event loop?
It's the slot I'm more worried about. The thing is you access the "txJointAngles" variable from both the main thread and the worker thread. It may happen that you iterate over the container in the "poseDistance" method and at the same time "overwrite" it with a new object using the slot ran by the main thread. This is a classical example of accessing a single variable from multiple threads and requires synchronization. If you not synchronize the threads, the least that can happen is a wrong result of poseDistance() or wrong execution of transmit() (as they both access the variable) and at worst your application will eventually crash (well... that's not the worst at all that can happen but it's still bad).I still don't understand why it's a bad thing if the main thread handles the signal. What exactly goes wrong?
By the way, if you keep a pointer to the robot interface in the player, there is no point in using signals and slots. Either get rid of that dependency or call appropriate methods directly (probably guarding access to a shared variable with a mutex or such).
Bookmarks