Hi Eugene, --- Eugene Alterman <eugalt@verizon.net> wrote:
Just to be precise, if asynchronous i/o is real (not emulated) you don't have to do anything for the operation to be performed, and run() will just demultiplex completion events.
True.
This BTW brings up a question of possible portability issues resulting from such a difference in behavior.
The actual behaviour is implementation-defined. That is, the operation may be performed at any time from when the async_*() call is made, but ultimately a run() call is still required. In practice this variance in implementation-defined behaviour has not been an issue, provided run() is used appropriately. There are many other issues that can also affect the observable effects of operations, such as buffering, Nagle algorithm, OS scheduling, latency and so on.
I also think that 'run' is not descriptive enough, especially if the class name becomes 'io_system'. Something like dispatch_events() may be?
Since the run() function does more than just dispatch completion handlers, I'm not sure that dispatch_events() sufficiently reflects what it does, or the requirement that it be called for asynchronous operations. To my mind, run() reflects that you are lending your thread to the demuxer (or 'io_system') so that it may perform whatever work is required. That's not to say that I'm particularly attached to the name run(). Any other suggestions? Cheers, Chris