Re: [boost] Aaron's Informal Proposal for a Universal Demultiplexor for Boost

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2004-09-14 16:07:56

Christopher Kohlhoff wrote:
> In your wiki article you ask us to forget about the event handling
> patterns, however I think the choice is fundamental to the design and
> use of such a demultiplexing API. In your discussion you seem to imply
> a reactive model (i.e. "tell me when i can take action without
> blocking") when you talk about things like an on_file_readable event.
> 
> In developing asio I chose to use the proactive model (i.e. "start an
> operation and tell me when it's done"), aka asynchronous I/O, because I
> saw it as providing numerous advantages.

I agree completely with your points about the merits of the proactive
pattern.

It is my intention that, unlike most frameworks that lock you into a
monolithic demultiplexor, both proactive and reactive patterns will be
usable.

Its my general feeling that the choice of event handling pattern has a
lot less to do with personal preferences, and more to do with what is
imposed by conventions of the problem domain, design constraints,
managerial decision, and third-party libraries.  If a demultiplexor
library espoused one particular paradigm, it would be come useless to
other incompatible paradigms.

In particular, it is up to objects themselves to implement the 'hooks'
that their users may use, which might be proactive, reactive, or
something else.

The basic_demultiplexor itself is constrained to some degree by its
implementation and by its minimalism.  In the case of on_file_readable,
this is necessary rather than a proactive scheme because it doesn't
actually know anything about read(), etc.  That doesn't stop a socket
class from implementing a proactive interface.

Aaron W. LaFramboise