Re: [boost] singleton asio::demuxer as default? (was:asioformalreview begins)

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-22 06:32:39

Hi Eugene,

--- Eugene Alterman <eugalt_at_[hidden]> 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