Boost logo

Boost Users :

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2004-10-21 17:24:45


On Thu, 21 Oct 2004 Aaron W. LaFramboise wrote:

> I'd just like to point out that I intend to share a prototype design of
> a demultiplexor.

Great. Your previous posts and the previous discussion motivated me
to take a look at how the demultiplexer was coupled to the socket
classes, and prompted me to better define the interface between them.

The interface that I have is now:

     template <typename Impl>
     class demux
     {
       template <typename Arguments>
       demultiplexer_error add(Arguments&, bool notify=true);

       template <typename Arguments>
       bool remove(Arguments&, bool notify=true);

       bool handle_events(long timeout=-1); // one shot
       void run(); // until stop()
       void stop();
       void notify(); // eg, new events to handle
     }

The tricky bit seems to be creating concrete Argument classes,
which provide the information about the resource the demultiplexer
should wait on, possibly the type of event to wait for, and the
function it should call if an event occurs.

The solution I have implemented uses composition of othogonal
classes, with the composition controlled by the concrete
type of the demux implementation, the type of resource, and
the operation being performed on the resource.

An example:
   A waitable timer needs to provide a handle a callback.

   A socket wishing to do asynch io with proactor style
   completion notification using a windows event object
   demultiplexer needs to provide an OVERLAPPED structure
   an event object, and a callback.

The concrete Arguments type computed in these cases provides
what is needed, with the user consistently specifying just the
handle and callback in each case.

Does that make any sense?
Does that compare somewhat to your proposal?

Hugo


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net