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.
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. BTW, I've yet to have time to do a review (I have a major deadline Dec 23, then xmas stuff for a few days). However, I've tried to follow some of the comments. One of my biggest problems with asio, when I tried it several months ago, was the poor support for datagram/multicast apps. I've seen that you have addressed some concerns (at least according to some comments). Could you please specify some details of the mcast improvements? Also, the motivation for your own thread implementation is an all-header implementation of asio. Why do you need an all-header implementation? In the earlier requirements for a boost network library, NOT having an all-header implementation was one of the requirements. Personally, I do not like all-lheader implementations, especially for system related components. They pull way too much junk into the namespace, especially under any flavor of Windows (though linux has its own problems there as well). Lots of macros, and other junk to pollute and cause problems -- not to mention the additional compilation time... What's wrong with a library-based implementation? While I haven't played, I assume it works under BCB ;-)