Rework async system

[markusobi]

• Fixed ~WorldInstance calling bgfx functions from non-main-thread (i.e. if exception occurs in GameSession::createWorld)
• If m_EnableMultiThreading is set to false, all tasks will be executed with policy MainThread (mainthread->mainthread is immediately). This makes tracing exceptions much easier, when being thrown in non-main-thread
• reworked BaseEngine::executeInThread. Now directly returns a future, which was created by a promise.
• It is now easily possible to transfer results of asynchronous operations. Example:

  console.registerCommand("sum", [this](const std::vector<std::string>& args) -> std::string {
      auto n = n = std::stoi(args.at(1));
      auto fut = this->m_pEngine->executeInThread<std::unique_ptr<int>>([n](Engine::BaseEngine* engine) -> std::unique_ptr<int> {
          int sum = 0;
          for (int i = 0; i < n; ++i)
              sum += i;
          return std::make_unique<int>(sum);
      }, Engine::ExecutionPolicy::NewThread);
      return "result: " + std::to_string(*fut.get());
  });

  (this example actually doesn't make much sense, since it blocks in the main thread until the worker thread finished)

[markusobi]

Should I refactor the whole executeInThread system into a separate class?

[markusobi]

@ataulien I've refactored the threading stuff into it's own class: JobManager The JobManager does not have any dependency (BaseEngine is forward declarated). The BaseEngine has got a JobManager (public) member variable. The two execute functions executeInThread and executeInMainThread are still in the BaseEngine and are simply calling the JobManager's functions of the same name. Since they are only wrapper functions, I could remove them and refactor all usages.

Which of the following variants do you prefer?

• m_Engine.executeInMainThread<void>(...)
• m_Engine.m_JobManager.executeInMainThread<void>(...)
• m_Engine.getJobManager().executeInMainThread<void>(...) with JobManager being private member

[ataulien]

@markusobi Sounds reasonable. I would prefer something along the lines of m_Engine.getJobManager().executeInMainThread<void>(...).

Having the method directly inside the engine would make the code less cluttered, on the caller-side, but it would also lead to a more bloated engine-object. We would have to wrap stuff like loading textures, etc too, to stay consistent.