Re: [boost] asio formal review begins

Hi Jeremy, Unfortunately this flag doesn't seem to be available on Solaris, which does raise SIGPIPE too. It also doesn't work with writev.
I use this code: ... sig::action sa; sa.set_handler( SIG_IGN); sig::action old_sa( sa.run( SIGPIPE) ); boost::shared_ptr< void > guard( static_cast< void * >( 0), boost::bind( & sig::action::run, old_sa, SIGPIPE) ); ::write(...) ... sig:action abstracts struct sigaction, clib function ::sigaction and so on. After sa.run( SIGPIPE) the signal is ignored and write would return EPIPE. The shared_ptr resets the original signal handler after getting out of scope. Oliver

<Oliver.Kowalke@infineon.com> writes:
Hi Jeremy, Unfortunately this flag doesn't seem to be available on Solaris, which does raise SIGPIPE too. It also doesn't work with writev.
I use this code:
... sig::action sa; sa.set_handler( SIG_IGN); sig::action old_sa( sa.run( SIGPIPE) ); boost::shared_ptr< void > guard( static_cast< void * >( 0), boost::bind( & sig::action::run, old_sa, SIGPIPE) );
::write(...)
...
sig:action abstracts struct sigaction, clib function ::sigaction and so on.
After sa.run( SIGPIPE) the signal is ignored and write would return EPIPE. The shared_ptr resets the original signal handler after getting out of scope.
As I mentioned in another message, at least on Linux, sendmsg can be used as replacement for writev that allows specification of MSG_NOSIGNAL. Your code might potentially be useful on Solaris and other platforms that do not support disabling the signal through mechanism like MSG_NOSIGNAL, although your code seems to introduce quite a lot of overhead per write call. -- Jeremy Maitin-Shepard

Hi Oliver, --- Oliver.Kowalke@infineon.com wrote: <snip>
sig:action abstracts struct sigaction, clib function ::sigaction and so on.
Is sigaction safe with threads? Doesn't it set the process-wide signal handler? If so, that won't work if a process might be doing writes from multiple threads. I've been doing a bit of reading along the lines of what Jeremy suggested, and it seems like best thing at this stage is: - On linux use sendmsg with the MSG_NOSIGNAL flag. - On Mac OS X use setsockopt with SO_NOSIGPIPE option. - Solaris ... ??? Unfortunately the best option at this stage does seem to be globally ignoring the signal. Cheers, Chris
participants (3)
-
Christopher Kohlhoff
-
Jeremy Maitin-Shepard
-
Oliver.Kowalke@infineon.com