Hello Simon, I've made some modifications because defer_pool::stop was not waiting for finishing all work items if thread_sleep was removed in your examples. - defer_pool : work items are queued into a thread pool; if defer_pool::stop returns, all work items have been processed - defer_thread : each work item is processed in a new thread; threads are never joined (call and forget) - defer_null : work item is processed in main thread -defer_point : interface I believe that only defer_pool needs a list of work items. defer_pool with one thread in the pool should be mimic your implementation of defer_thread. So I would use defer_thread in a create-and-forget manner. Oliver

Your suggestion about adding timed enqueue/dequeue and a limitation on the amount of queued work items raises an interesting point about how this kind of library could be structured. I'd see those features not as part of the defer_point, but as classes built on top and parameterised with an instance of a defer_point.

A thread_queue parameterised with a defer_point would still keep all the logic about high/low water marks and simply use the defer_point as a means of getting a callback in order to service the request (i.e. by calling into the queue consumer code).

A bit cheeky i know, but would you be willing to write an implementation of thread_queue along the above lines as a test of defer_point?