Re: [boost] asio formal review begins
Hello Christopher,
Hi Oliver, Multicast support is there - see the example in libs/asio/multicast and the boost::asio::ipv4::multicast namespace.
Sorry - I was searching in the 0.20 version (as I could see 0.3.6 contains multicast).
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.
I don't agree. Only if write/sendto is called on a closed socket SIGPIPE should be blocked by your library. In all other cases the user defined signal handler for SIGPIPE should be called. In your solution the user can only ignore SIGPIPE globally (even if the signal is generated from other sources than sockets) or install its own signal handler - and so be forced to distinguish between SIGPIPE from socket and other sources (problem - multiple sockets; which socket has generated the signal?).
EINTR is not handled in the reading/writing functions? The blocking functions will return error::interrupted in this case.
Wouldn't it be better to call read/write again if EINTR is returned?
Is it correct, that asio doesn't use AIO System Interfaces from the OS (like aiocb, aio_read, aio_write, aio_suspend, ...)? However these function don't support sockets on Linux yet (AFAIK, it may just be that they don't support sockets efficiently)
Support for kernel AIO has been included in the 2.6 Linux kernel. AIO read and write on sockets doesn't return an explicit error, but quietly defaults to synchronous or rather non-AIO behavior. See http://lse.sourceforge.net/io/aio.html
and for solaris I'm planning to support /dev/poll first.
/dev/poll is also supported by Linux. So long, Oliver
--- Oliver.Kowalke@infineon.com wrote:
Only if write/sendto is called on a closed socket SIGPIPE should be blocked by your library. In all other cases the user defined signal handler for SIGPIPE should be called. In your solution the user can only ignore SIGPIPE globally (even if the signal is generated from other sources than sockets) or install its own signal handler - and so be forced to distinguish between SIGPIPE from socket and other sources (problem - multiple sockets; which socket has generated the signal?).
I agree, what you describe is the ideal solution. However I was unable to work out how to ignore the signal just for some operations. Can you tell me how to do this?
Wouldn't it be better to call read/write again if EINTR is returned?
IMHO no, because this can prevent an application from shutting down if they have set a custom handler for SIGINT etc. I think it is better for the application to handle error::interrupted so that it can check some app-specific flag to determine whether to shut down or resume the call.
/dev/poll is also supported by Linux.
I believe epoll is the close equivalent for linux, and it's already the default for asio on 2.6 kernel. Cheers, Chris
Christopher Kohlhoff <chris@kohlhoff.com> writes:
--- Oliver.Kowalke@infineon.com wrote:
Only if write/sendto is called on a closed socket SIGPIPE should be blocked by your library. In all other cases the user defined signal handler for SIGPIPE should be called. In your solution the user can only ignore SIGPIPE globally (even if the signal is generated from other sources than sockets) or install its own signal handler - and so be forced to distinguish between SIGPIPE from socket and other sources (problem - multiple sockets; which socket has generated the signal?).
I agree, what you describe is the ideal solution. However I was unable to work out how to ignore the signal just for some operations. Can you tell me how to do this?
Yes, simply include the MSG_NOSIGNAL flag in the call to send or sendto.
[snip]
-- Jeremy Maitin-Shepard
Hi Jeremy, --- Jeremy Maitin-Shepard <jbms@cmu.edu> wrote:
Christopher Kohlhoff <chris@kohlhoff.com> writes:
I agree, what you describe is the ideal solution. However I was unable to work out how to ignore the signal just for some operations. Can you tell me how to do this?
Yes, simply include the MSG_NOSIGNAL flag in the call to send or sendto.
Unfortunately this flag doesn't seem to be available on Solaris, which does raise SIGPIPE too. It also doesn't work with writev. Cheers, Chris
Christopher Kohlhoff <chris@kohlhoff.com> writes:
[snip]
Yes, simply include the MSG_NOSIGNAL flag in the call to send or sendto.
Unfortunately this flag doesn't seem to be available on Solaris, which does raise SIGPIPE too. It also doesn't work with writev.
I don't know about Solaris, but maybe SIGPIPE could be blocked only on Solaris. Instead of using writev, you can use sendmsg on Linux. -- Jeremy Maitin-Shepard
participants (2)
-
Christopher Kohlhoff -
Jeremy Maitin-Shepard -
Oliver.Kowalke＠infineon.com