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

From: simon meiklejohn (simon_at_[hidden])
Date: 2005-11-26 23:24:55

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