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