Anthony Williams-4 wrote:
In practice, just providing the interface to launch_in_pool has proven difficult as it returns a future value. The problem is nailing down a future interface which is both expressive and can be implemented in a lightweight manner.
Could you elaborate more, which difficulties? What is missing on the current Future proposals for you?
There are at least two things which still needs be solved: 1. How to wait for multiple futures
My futures prototype at <http://www.justsoftwaresolutions.co.uk/threading/updated-implementation-of-c++-futures-3.html> handles that.
I'm not very satisified with that interface, but I may very well be missing something. For instance, can you implement additions of futures on top of your interface? future<int> operator+(future<int>, future<int>). Rather than having to gather up all futures from all over a program and having to wait for them in one single place, I think it would provide a lot of value if you could compose futures to an arbitrary depth. That is, I do not want a construct that is similar to POSIX select or Windows' WaitForMultipleObject as they really mess with program structure. Also, your dynamic wait_for_any implementation requires O(N^2) operations in cases where you want to wait until one value is ready, do something, then resume waiting until the next one ready and so on. Anthony Williams-4 wrote:
2. How to employ work-stealing when one thread waits on a future
An expressive solution is to allow some callback hooks (for future::wait and promise::set) but that is quite hackish. IMO you should not be able to inject arbitrary code which is run in promise::set via a future object that runs on a completely different thread.
Yes. This needs to be internal to the implementation, which requires the future and thread pool to cooperate.
It doesn't necessarily need to be internal. It could be code aimed to be executed in a thread pool should explicitly wrap their waiting: // Will employ work stealing if this_thread is a worker thread void wait_or_work_steal(future<...>) I'm far from convinced that an automagical solution where futures cooperate with a single instance thread pool is the best. That means a lot of coupling and I'm not sure it will provide much value. I think a future value is such an important construct in its own right, that thread pool design decisions should not be allowed to affect it very much. Thread pools need a really lightweight task abstraction to allow extraction of finer grain task level parallelism, i.e. futures should try to be lightweight (if std::unique_future really should be the return value from a thread pool). Other than this, I'm not sure how much a thread pool should be allowed to affect the future design and implementation. IMHO, an imagined thread pool implementation should be one of many "test users" of a future implementation to see if the API and implementation is satisfactory. Johan -- View this message in context: http://www.nabble.com/-threadpool--relation-with-TR2-proposal-tp19452045p197... Sent from the Boost - Dev mailing list archive at Nabble.com.