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