Re: [boost] boost::defer - generalised execution deferral

From: Oliver.Kowalke_at_[hidden]
Date: 2005-12-13 04:03:15

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?