Hi Aaron, --- "Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> 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