I’m going to chime in here because I’m a cranky old man and this is one of my industry wide pet peeves. I’m not belittling, disparaging, or attacking any singular individual though some might think that.
Let me also preface this by stating that if you are forced to use Qt you have my deepest sympathies. That application framework is really showing its age. The single-thread-i-ness of its design really hampers good development.
I started out in IT when the Commodore Super PET ruled the land. 8-inch floppies were on their way out and IBM had yet to even think about introducing the PC. Back there and then we were all forced to go to college to get a degree. On that educational journey we were forced to learn a great many things. None of us ever used the advanced math, but most of us used everything else.
This was the time of real computers and real operating systems. We neither had nor wanted threads. The process design of each OS was so robust it was trivial to create many sub-processes. The process level accounting was so complete we knew any process launched as a sub-process, though it was a full stand-alone process, would be cleaned up with the parent went away. The operating system charged every nanosecond of CPU, byte of memory, and block of storage to an account for each user. Many users were leasing time either directly or through a company and we charged for everything. An RL02 1.2 MEG removable disk pack cost $5,000, so yes, we charged for everything and the OS had to have that level of process accounting.
People who come from the platforms designed to have hundreds-to-thousands of simultaneous users always design from a process level, not thread. While we can and do use threads, we limit them to low priority things that don’t really matter.
Dennis Richie, when creating UNIX, was creating a single user OS that could run a few batch/background tasks. This was to be in stand-alone telephone switches and the whole terminal/login thing was just so someone could set up the switch or monitor it during trouble shooting. He created something so light it doesn’t even qualify as a thread on the bigger machines. Then he and/or the C language group created something even lighter they called a thread.
Linus was basically cloning UNIX despite how such a statement honks him off. He didn’t design it to handle thousands of interactive users charging back for every resource used. This is why Linux and UNIX are notorious for “dangling threads.” The problem has even bubbled its way to Java and many other VM based languages.
People who have never worked on anything other than an x86 or ARM based system (many of whom also never got an IT degree) try to do everything with threads. Sadly, threads are not a good tool. They are a roll of duct tape.
Docker containers are the latest attempt by the Linux world to fix a completely botched process design. You can read my previous answer about how to communicate across containers here. For instructions/pointers on how to assign containers to cores, start here.
If you are running a single executable under a Yocto built Linux, you can use the C system() function to create additional processes. You also need to install taskset in your build if it is not already there.
Doc showing how to move an existing PID to a core.
Launch a program from command line tied to a specific core.
Because of the feeble process accounting in Linux, what you launch won’t go away when the launching process dies. You will have to defend against auto-launching processes that didn’t die when your primary fell over and got auto-restarted by some kind of watchdog application. A “lock file” is not a good or reasonable choice unless you are creating it on a RAM disk that goes away with restart.
Most people who didn’t work on the big stuff stumble bad when it comes to process synchronization and restart coordination so they reach for Docker. Not a perfect solution but a kinda-sorta-good-enough-for-many solution.