Boost logo

Boost :

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.


> 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. -
-- rrivera/ - grafik/
-- 102708583/icq - grafikrobot/aim - Grafik/

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