Before only m_threadCount was protected by a mutex but not the rest of the bools that are read/written from different threads. This replaces them by atomic values removing the need for the mutex and protecting the previously unprotected bools, except for m_autoDestroy that it's only set before starting the thread.
Simplify thread handling by using std::thread.
When in deamon mode, just wait for the Stop signal instead of looping constantly, in a way that doesn't affect responsiveness.
Wait until new jobs or a Stop signal instead of looping, in a way that doesn't reduce responsiveness.
I've run into an issue when compiling for linux installer package (cross compiling for many CPU architectures).
The compilation for armel breaks with:
After searching found this explanation. In short (read the link for details):
Do you have an alternative solution without promise/future maybe? If you don't I would need to
It's GCC 5.2.
Even though the problem seems to be fixed in GCC 7.0 I cannot easily drop support of older GCC versions. Armel is an important platform. It was a pain for some users when I migrated to C++11/14 with requirement for GCC 4.9. Even GCC 4.8 supported (but only when compiling in release mode) and I intentionally don't use some C++ features not available on GCC 4.8 in order to maintain compatibility.
Changing system requirements of NZBGet to higher GCC version is possible but it has to bring a big advantage to the project. A simple "there is one place where we could use a new compiler feature" isn't such case. The switch from C++98 to C++11/14 was such case.
If promise/future or async or packed_task will allow to for example increase performance to 10% then the switch may be worth it. If these features just allow to save a couple of lines of code then no.
Maintaining compatibility with many platforms is indeed painful and has costs.