Hi Jody, --- Jody Hagins <jody-boost-011304@atdesk.com> wrote:
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.
I guess you must be doing some pretty hard-core networking to be concerned about this level of detail. Can you describe a use case that would make such a feature widely useful? Some hard numbers on performance differences would be quite interesting.
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?
The standard multicast socket options are implemented in the asio::ipv4::multicast namespace. They are: add_membership (IPPROTO_IP/IP_ADD_MEMBERSHIP) drop_membership (IPPROTO_IP/IP_DROP_MEMBERSHIP) outbound_interface (IPPROTO_IP/IP_MULTICAST_IF) time_to_live (IPPROTO_IP/IP_MULTICAST_TTL) enable_loopback (IPPROTO_IP/IP_MULTICAST_LOOP)
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?
From comments, you'll seed that some people prefer header-only and others don't.
It's on my to-do list to investigate a library implementation, but this would be an option, not mandatory. The goal of the library implementation would be to hide away the system headers. However, a few things need to be considered: - Much of the library is implemented in templates, so it is likely that only the lowest level OS wrappers would be in a library. - I am very concerned that any compilation firewall technique used does not introduce additional memory allocations. I am not yet sure about the best way to achieve this. Some declaration of system types may be required (albeit in a namespace), for example.
While I haven't played, I assume it works under BCB ;-)
Yes, mostly :) Cheers, Chris