So much to say here, so little time.
First of all, you can pass a (void *arg) parameter when you start a thread. The thread could use a local automatic variable (allocated on the stack) to keep track of itself. There’s also a way to allocate a thread specific piece of memory.
But something smells bad here. Sure if I had say a board that had 64 inputs and a trigger for each, and the whole thing was symmetric,… then I’d be thinking about a process with 64 threads.
But if you are used to programming on a Windows system, and you are used to creating a gigantic process with a thread for everything, yes you can do this in QNX, but you are missing a lot. Before QNX 6, there were no threads at all, just lots of processes that communicated mostly through message passing, but occasionally using shared memory. Separating things logically into separate processes has lots of advantages and few disadvantages. That is unless you don’t care about robustness.
There, enough heavy handed opinion.
BTW, thread_pools are a nice add on, but they don’t give you anything you can’t create yourself with the more primitive pthread*() calls. So if a thread_pool matches the functionality you want, I’d use it. I agree with the other poster that if you just need 64 threads and that’s all, just create them. Thread pools make the most sense if the number of threads may grow and shrink and you want to conserver resources.