A bit of a look at the callback facilities of the asio library leads me to think there are some differences between that scheme and the one i'm proposing. These differences make it worth expanding on my proposed Defer model at least for the purposes of comparison. Defer has the following characteristics 1. Polymorphic defer strategies - a base class DeferPoint defines a simple protocol for requesting and receiving callbacks. 2. Concrete defer agents inherit from DeferPoint, and implement its protocol in custom ways (dedicated thread, thread pool, callback int the caller thread, win32 gui event notification etc). 3. Deferral Styles derived from DeferPoint are abstract classes from which to derive concrete deferrers. Client code can use the DeferStyle names in their interfaces to specify their requirements/compatibilities. (things like - thread affinities, thread multiplicity, re-entrancy policy) This is a fairly old-school way to structure things but i believe it leads to greater deployability than doing a generics/templates approach at this base level. Its still possible to build generic code on top - such as using boost::function to define work items like boost::thread does. Benefits of this approach compared to asio 1. Large existing non-template code-bases can be made Defer-friendly comparitively easily - a new constructor parameter here, a deferral request there. 2. The DeferPoint base class allows client code to benefit from different deferral styles without needing to be templated. 3. Strong types for Defer Style concepts allow for compiler enforced reasoning about how to hook different components together. 4. more easily able to hook in to the windows event model and other ad-hoc schemes. Cheers Simon