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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-12-22 15:56:57

Jody Hagins wrote:
> On Thu, 22 Dec 2005 23:29:53 +1100 (EST)
> Christopher Kohlhoff <chris_at_[hidden]> wrote:
> 
>>If I'm understanding you correctly, what you are after is a
>>single program, where you you have some sockets using one
>>demuxing method (say epoll) and other sockets using (say)
>>select? Interesting.

Somewhat.

> Note that each is good for specific things.  I have tests and numbers
> that show select() and epoll() running circles around each other in
> performance, depending on the way they are used.  Mixing the different
> types of use-cases causes both methods to degrade.  Thus, I think it is
> very reasonable to put some sockets into a select-based method, and
> other sockets in an epoll-based method.

Strangely it's not having multiple methods on different FDs at the same 
time that I had in mind. Although thinking about it I can see how having 
the choice would be good. 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 ultimately my concerns with Asio are about the same as those pointed 
out by Darryl, much better than I could have. I find it distressing that 
users are forced to pay for this particular Proactor implementation, in 
it's most generic form, when there are many situations under which it's 
not needed at all or when I want to implement a different Proator or 
other dispatch implementation. In a strange way it reminds me of 
libraries like ACE where to use 5% of it you have to use 90% of it.

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.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org