"Any interest in...?" This post asks the above question in relation to a possible library boost::defer which would live half-way between the Herb Sutter active/future thread model and the semi-raw facilities of boost::thread. Deferral here means 1. Do something later 2. Let something else decide which thread will execute the work Facilities like boost::function offer a way to wrap up a unit of work that can be deferred. (UOW) boost::defer would offer a way of posting the work unit to a Defer Point object that would call the unit of work in whatever is the appropriate thread. The Defer Point acts as a queue for scheduled work items Different polymorphic styles of Defer Point would implement different strategies for which kind of thread does the callback 1. single thread - owned by the Defer Point 2. Pool - staic or dynamic pool of threads owned by the Defer Point 3. win32 hidden window (dispatches callback on a gui thread) 4. NULL - Calling thread callback (i.e. do it now in the caller's thread) 5. Gating - Calling thread with mutex protection (serializes multiple threads thus protecting the called code) Any given defer point object can either be dedicated to a particular task, or can be shared throughout a program giving rise to a variety of ways of using system threads 1. One single thread defer point, reused throughout a program -> cooperative multi-tasking 2. win32 hidden window reused throughout -> cooperative multi-tasking on the gui thread 3. as above, but with another dedicated thread Defer Point (or pool) used for slow background tasks I've found these threading concepts to be useful in large-scale projects where multiple libraries want to do callbacks into some application code. Defer Points allow you to parameterise those libraries in such a way as to play nicely with eachother - deferring their callback strategy to a style defined by the programmer integrating the libraries into the final app. Its also handy where multiple entities in a program need to call into eachother, potentially recursively (A calls B calls A calls B) Better to break this recursion with queues of work items. So - any interest in more concrete code? More detailed explanations and scenarios? Cheers Simon