This post suggests apply a Decorator like pattern to the Defer/Asio::demuxer style libraries. Where previously a component requests a deferred execution of a function f() it would now be possible to get f() called at the end of a chain of wrapping functions a( b( c( d( e( f() ) ) ) ) ); the decorating functions would be of the form void func( boost::function( void (void) ) ) i.e. they can be composed into a chain using boost::bind Of itself that looks pretty trivial. Where it becomes more interesting is when you consider 1. who injects the extra functions and when. 2. what can be done inside those function objects looking at the second - why would we want to decorate the eventual callback? Here are some possibilities 1. try to obtain some resource. If its not obtainable, then return without calling the decorated function 2. wait on a lock before proceeding (i.e. similar to the defer_mutex concept) 3. Create an object on the stack that helps the decorated callback - e.g. add a logging context string ("ACME callback" so when the eventual code calls LOG( "hello" ) what gets logged is "[ACME callback]hello" Apply this repeatedly - so the defer object, the defer requester and the callback target each insert a logging prefix, so LOG("hello") becomes "[DeferPool][Acme callback][My acme observer]hello" The three components that might have interesting things to insert into the chain are: 1. the owner of f() (i.e. the component registering for a callback) when it registers the callback. Lets say it inserts d() and e(). 2. the originator of the callback (e.g. the parser component from a prevoius discussion) when it initiates the callback, or when the client callback is registered 3. the provider of the defer object (e.g. main()), when it constructs the defer object. In addition to code to be executed in the chain of every callback its desirable to insert code that be executed just once by each thread in a pool (e.g. to get the pesky CoInitializeEx() called before servicing requests). Lets call these Base Thread Decorators. It may help to illustrate if i show a pseudo stack trace at the point where a callback has finally reached the innermost callback (f() in the above example). [top of stack] f() ...client supplied decorators e() d() ... callback originator decorators c() ... per defer object decorators (provided by main) b() defer_point::service_deferrals() - the thread waits for work .... base thread decorators (provided by main) a() - e.g. call CoInitEx... .... thread entry point defer_point::thread_entry() .... [bottom of stack] ------------------------------------ So i guess the point is - defer_point could usefully provide some methods for injecting decorators to be applied to all callbacks, as well as some methods to help callback recipients and callback originators to decorate their callbacks. Does this seem a useful addition? Just more crazy talk from a thread-obsessed idiot? Cheers Simon Meiklejohn