Hi Rene, --- Rene Rivera <grafik.list@redshift-software.com> 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