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

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2004-09-14 21:16:18

Hi Aaron,

 --- "Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> wrote: 
> 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.

Perhaps, but my experience in using asio (as opposed to writing it) has
been that:

- A proactive interface is all that I have needed for sockets.
- Other reactive or even blocking interfaces can generally be
efficiently wrapped by proactive ones.

Therefore, I have attempted to use an acceptable set of trade-offs that
suits most problems, and to my mind a proactive interface fits the
bill.

But should that not be sufficient, I should point out that the demuxer
in asio is extensible using a similar idea to std::locale's facets. So
it is possible to override the implementation of a socket, or to even
include a entirely new reactive-based resource.

> 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.

It is my feeling that attempting to define a demultiplexing interface
in such a way is drawing the line of abstraction too low. However
perhaps we are talking about different things :)

My focus in asio has been on defining a C++ interface for using sockets
or other OS objects asynchronously, but while leaving maximum freedom
for the implementor (i.e. me until now) to use the best mechanism for a
particular platform by default, whether that be native async I/O or a
reactor-based solution.

The demultiplexor you talk about sounds to me more like an interface I
would use to implement a socket (for example) on some platforms, but
not necessarily on all.

Regards,
Chris