   Future and promise suitable for games?
I've been playing around with the future and promise mechanism in C++11. I've previously used task-based multithreading systems, where a set number of threads pull tasks from a queue - and the tasks generally do a big chunk of work each. I'm not convinced that futures and promises are particularly suitable for games, since they seem to be designed for smaller asynchronous tasks like I/O or handling UI events. Also, as far as I can tell, a new thread is allocated for each task which gets scheduled - which seems a little inefficient. Wondering what everyone's take on this is? Cheers!
  The concept itself is at least quite useful. There are plenty of cases where you need to wait for a particular series of tasks to finish, even if those tasks are batched to a large job system. They're very similar to any message system, albeit they only fire "once" and remember whether they've already fired or not.Modern games also do a lot of request/response things to remote servers for DLC, friends list and status update, micro-transactions, etc. which is a great use of futures (or even async/await if it ever becomes widely available).Remember, not every piece of code in a game is in some inner loop running thousands of times per frame.The specific implementation of std::future may leave something to be desired. I don't know that there is much collective wisdom in the games industry to make a call on it one way or the other. A future can conceptually be tasked out to a thread pool; I don't know enough about the specific implementations of any to know if they are using a thread pool or not, however. You can write your own without much difficulty if you need to, however, and you could even replace std::future at a later date easily enough if you start writing code relying on it then later determine it has issues in its implementation.   