Re: [boost] asio formal review begins

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-12 06:27:52

Hi Oliver,

--- Oliver.Kowalke_at_[hidden] 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