Hello, During discussions on possible extensions to Boost.Threads, concept of Futures came up rather frequently. Below, I’d like to introduce a particular implementation available at www.rhapsodia.org of which requirements were defined as follows: 1. Provide means to register exception types with a "Future Registry". Rationale: I find it imperative that users should not have to define a list of exception types on each invocation yielding a Future object. Instead, provide the ability to register exception types with a Future Registry and bundle it with Future objects. I feel that compile time registration should be sufficient. 2. Work under the assumption that asynchronous invocations returning Futures and system threads are not coupled. In particular, Futures implementation should not relay on joining with a particular thread to perform synchronization for returning results. Rationale: Although most prevalent, the technique of joining with a particular thread to synchronize on returning result is too limiting. It implies that each task be run on a dedicated thread, specially created to handle it and destroyed to meet with a caller using a Future. Although this approach may be adequate under certain conditions, it generally tends to be expensive on system resources and disorganizes the application. For example, it’s impossible to control the number of concurrently running threads. It may also perform poorly if executed code happens to run shortly as the overhead of creating a thread and cleaning up after it may be significant. More robust approach is to use a queue and a thread pool for running tasks. This adds complexity on the synchronization side, as we can no longer rely on a lifetime of a thread to join with Future’s result. 3. Ability to utilize Futures with arbitrary code without explicit support for them. Rationale: For implementation to be widely adopted, it should be possible to turn just about any function call into a Future-armored asynchronous invocation. No explicit thread synchronization primitives should be used as well. 4. Implement using existing Boost.Threads facilities only. Rationale: Boost.Threads library provides enough support to implement Futures paradigm that meets requirements listed here. 5. STL and Boost compatible. For example, storing Futures in an STL container. Be strongly typed. Futures implementation and usage patterns must naturally coexist with STL and Boost code. Additionally, compile-time type validation is key to safer code. Attached is a sample file from Rhapsodia library showing the use of Futures. Regareds, Slawomir Lisznianski [ www.rhapsodia.org ]