Hi everyone,
We would like to introduce std::thread as a new backend in the vtkSMPTools backend.
As it won’t add any external dependencies it can be useful for user who can’t use directly OpenMP or TBB (for example on Windows).
We do not expect the same performance as with OpenMP or TBB, but this version should be used as replacement of the Sequential backend for architectures with limited access to third party.
Let us know if you have any feedback about this new change,
Timothée
That sounds great Timothée, thanks!
BTW/FYI: OpenMP is not convenient on macOS either, since the AppleClang compiler, unlike the regular open source Clang, does not support OpenMP. 
Sounds great to me too. Could this conceivably be enabled for the binary Python wheels on PyPI? (what compilers are used for those?). I imagine they are currently built with serial backend due to difficulties of getting/bundling e.g. TBB?
Adding more multithreading by default sounds like a good idea.
Could this be added as a new backend processor which is used by default instead of a replacement for the sequential backend? Sometimes it can be useful when developing new filters, or in detailed debugging, to be able to run a debugger sequentially without any multithreading.
Sometimes it can be useful when developing new filters, or in detailed debugging, to be able to run a debugger sequentially without any multithreading.
+1 this is very important
The Native back-end will indeed be an additional one. We won’t remove the Sequential option.
Most excellent, I am really looking forward to what you come up with!