Hi Oliver, --- Oliver.Kowalke@infineon.com wrote:
what about multicast and raw sockets (ICMP, IGMP, ...)?
Multicast support is there - see the example in libs/asio/multicast and the boost::asio::ipv4::multicast namespace. There's no raw socket support at the moment, but I don't see any reason why it can't be supported in principle.
SIGPIPE is blocked by the ctor of basic_demuxer - I think it would be better to block SIGPIPE only in the functions reading from the socket and after that reset to the original signal handler.
But that would mean that the SIGPIPE is still delivered to the application, wouldn't it? That's not very nice since the default behaviour for SIGPIPE is to terminate the application. I chose to ignore SIGPIPE globally since most people writing portable applications would never want to know about it. If you do feel the need to handle SIGPIPE yourself, just specialise boost::asio::detail::signal_init so that it isn't ignored.
EINTR is not handled in the reading/writing functions?
The blocking functions will return error::interrupted in this case. For asynchronous calls implemented using a reactor (i.e. select, kqueue, epoll), all signals are blocked while the operations (read, write, etc) are being performed. The signals are unblocked again before returning to select (or kqueue or epoll) so that Ctrl-C and friends can terminate an application that's calling demuxer::run().
Is it correct, that asio doesn't use AIO System Interfaces from the OS (like aiocb, aio_read, aio_write, aio_suspend, ...)?
At the moment that's true, although an implementation is feasible. However these function don't support sockets on Linux yet (AFAIK, it may just be that they don't support sockets efficiently) and for solaris I'm planning to support /dev/poll first. Cheers, Chris