black-sheep

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 thi

> Please see here: https://github.com/electric-sheep-uc/black-sheep/blob/0735de... 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. Conceptually you have only maximum of two threads in any given part of this snippet, the one running the loop and the current instance of visThread. My guess is also that the loop thread spends most of its time waiting for the recently created threads to die. Why not have visThread only get created once and process a queue of events? Anyway without additional evidence you potentially flagged a bug in the c++ standard library rather than pthread_create.

There appears to be cases under high create/destroy scenarios where it returns zero, but failed to allocate memory for a thread during create. This is with tonnes of available memory (hence not a mapping error) and no exceptions thrown. That said, it's still entirely possible I've made a mistake. Please see here: https://github.com/electric-sheep-uc/black-sheep/blob/master... The idea is that you do preliminary processing of a camera frame before sending a neural network over the top.