Firstly, thanks for taking the time to look. > Creating and destroying threads in a tight loop (and blocking on their destruction, thereby reducing the point o

Firstly, thanks for taking the time to look. > Creating and destroying threads in a tight loop (and blocking on their destruction, thereby reducing the point of having many) seems like a bad idea. The purpose is that it's pretty much 100% always running a visThread (it's a neural network that takes about 100ms per image). The pre-process on the other hand runs in about 10ms, but there's no reason why it can't be run in advance (+). The neural network can't really be run on multiple cores safely, but it does have OpenMP (parallel loops). (+) It does create some latency in the output compared to the real world, but it's not a massive deal when it comes down to it. > Why not have visThread only get created once and process a queue of events? This is probably the best way to do this, but this was the lazy way with not too much overhead (I think) :) > Anyway without additional evidence you potentially flagged a bug in the c++ standard library rather than pthread_create. Possibly, I did run it through GDB and Valgrind, it reliably seemed to die in pthread_create, but that of course could have only been the trigger. It could also be the aggressive optimization [1]. [1] https://github.com/electric-sheep-uc/black-sheep/blob/0735de8f06a673a9c5de9a6cdc3f6c6f34681b53/source/CMakeLists.txt https://github.com/electric-sheep-uc/black-sheep/blob/0735de...