Boost logo

Boost :

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

Hi Rene,

--- Rene Rivera <grafik.list_at_[hidden]> wrote:
> 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.

> 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

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

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at