boost.asynchronous looks to have many of the same features/functionality as HPX. Can I ask why you chose to reimplement futures/lightweight thread pools/parallel STL/etc, rather than working on improving HPX to suit your needs?
I don't think the libraries have the same goals (or at least it seems to me so). Asynchronous is first of all an architecture tool focusing on organizing a whole application into thread worlds. The libraries also do not have the same design / tradeoffs. Asynchronous can make use of futures but encourages callbacks and tries to make these as safe as possible. The goal is to be as asynchronous (meaning non-blocking) as possible. It is no coincidence that I'm also the author of Boost.MSM. The encouraged design is a whole lot of state machines, each in its own thread (possibly sharing a thread), sending tasks to threadpools, TCP connections, etc. and waiting for callbacks. Future-based designs do not mix well with state machines' run-to-completion. The reason for the non-blocking focus is that I'm using the library at work in an industrial 24/7 application. When working on the production line, blocking is a disaster. If an algorithm goes astray, or simply takes longer than usually, blocking the production line results in huge costs. Crashes due to races also. Asynchronous provides ways to avoid both.
JB Disclaimer : I have contributed o HPX, but I'm not one of the "German HPC Guys" :) .
No hard feeling. I'm grateful for participation and the chance to explain the underlying ideas of the library. Thanks, Christophe