Re: [boost] [review] Asio formal review.

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-22 23:54:01

Hi Rene,

--- Rene Rivera <grafik.list_at_[hidden]> wrote:
<snip>
> My original contention is a compatibility concern. I want to
> be able to write a *single* program that for compatibility can
> run on Linux 2.4 and above. In such a situation I need to
> query the OS to find out the optimal (from my point of view
> not Asios' POV) method and instantiate/use it. Hence I am
> using more information than is available when Asio makes its
> optimization choice.

But if your use case is as you described before, where you only
have one or a small number of sockets, then why not just compile
for a Linux 2.4 target only? The select-based implementation
will do just fine since you've only got a very small number of
sockets involved, and you'll get your portability.

<snip>
> Another aspect of the current design I have problems with is
> that it forces a pattern of use that predicates dynamically
> creating a state machine path for handling the IO. In my
> previous test example it's a very simple FSM, where it
> basically goes back to the same node for all IO messages. But
> for more complicated interactions, like HTTP, SMTP, IMAP, POP,
> etc. such a pattern is suboptimal, perhaps not from a
> performance POV, but from a code modularity, maintenance, and
> verification POV.

Actually I believe the asio model lends itself more easily to
constructing intuitive, modular abstractions than, say, a
reactive model. This is because it allows you to compose a chain
of asynchronous operations and hide them behind a single
function.

For example, I could easily imagine a function:

  template <typename Handler>
  void async_http_get_content(
      asio::demuxer& demuxer,
      const std::string& url,
      std::vector<char>& content,
      Handler handler);

Internally this might parse the URL, resolve the host name,
create a socket, connect, transmit request, collect response,
close socket and finally invoke the application handler, all
asynchronously.

Other protocol interactions could be similarly encapsulated
behind an asynchronous interface.

Cheers,
Chris