Jody Hagins wrote:
On Thu, 22 Dec 2005 23:29:53 +1100 (EST) Christopher Kohlhoff <chris@kohlhoff.com> 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