Bug #92024 for IO-Async: Ignore SIGPIPE

Fri Jan 10 04:37:08 2014 leonerd-cpan [...] leonerd.org.uk - Ticket created

Subject:

Ignore SIGPIPE

Since IO::Async handles SIGPIPE it should mark these signals as ignored. May be best to do that locally though; in ->run or ->loop_once perhaps -- Paul Evans

Fri Jan 10 04:37:20 2014 leonerd-cpan [...] leonerd.org.uk - Broken in 0.61 added

Fri Mar 28 14:06:00 2014 leonerd-cpan [...] leonerd.org.uk - Correspondence added

It turns out that GTK (or Glib) ignores SIGPIPE anyway, so actually IO::Async::Loop::Glib->run has been ignoring SIGPIPE for all this time anyway. Probably the best thing to do is to have run do local $SIG{PIPE} = "ignore"; across the various loop implementations, and special-case any other run-like cases that might not be within run (e.g. Future->await cases) -- Paul Evans

Sun Nov 23 00:50:36 2014 TEAM [...] cpan.org - Correspondence added

There doesn't appear to be any support for explicitly *ignoring* signals, at least not according to documentation or IO::Async::Signal/Loop source. This seems like it could be a useful feature to add: $loop->ignore_signal('PIPE'); as distinct from: $loop->watch_signal(PIPE => sub {}); i.e. ignore the signal completely, rather than just providing an empty handler. Currently it seems the only way to do this would be a manual $SIG{PIPE} = 'ignore'; As for SIGPIPE, ignoring that signal is the first thing I do in any code, can't really see a case where the default behaviour is useful, so I like the idea of ignore-by-default (or at least an empty handler that just records the event via ->debug_printf). cheers, Tom On Fri Mar 28 18:06:00 2014, PEVANS wrote: Show quoted text

> It turns out that GTK (or Glib) ignores SIGPIPE anyway, so actually > IO::Async::Loop::Glib->run has been ignoring SIGPIPE for all this time > anyway. > > Probably the best thing to do is to have run do > > local $SIG{PIPE} = "ignore"; > > across the various loop implementations, and special-case any other > run-like cases that might not be within run (e.g. Future->await cases)

Sun Nov 23 00:50:36 2014 The RT System itself - Status changed from 'new' to 'open'

Sat Apr 04 07:58:04 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Sun Nov 23 00:50:36 2014, TEAM wrote: Show quoted text

> There doesn't appear to be any support for explicitly *ignoring* > signals, at least not according to documentation or > IO::Async::Signal/Loop source. This seems like it could be a useful > feature to add: > > $loop->ignore_signal('PIPE');

... Show quoted text

> Currently it seems the only way to do this would be a manual > > $SIG{PIPE} = 'ignore';

I'm not sure I see what functionality the former would provide that isn't trivially just the latter. To actually ask for the kernel to ignore a signal involves signal(sig, SIG_IGN); which is exactly what the latter plain perl code does. I don't think any loop implementation would ever need to do anything different. -- Paul Evans

Sat Apr 04 08:31:34 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

Given as the Glib loop already globally ignores it, and other event systems seem to do that as well, simplest seems to be just to globally ignore it here too. -- Paul Evans

Subject:

rt92024.patch

=== modified file 'lib/IO/Async/Loop.pm' --- lib/IO/Async/Loop.pm 2015-02-15 14:43:30 +0000 +++ lib/IO/Async/Loop.pm 2015-04-04 12:30:17 +0000 @@ -78,6 +78,8 @@ } } if WATCHDOG_ENABLE; +$SIG{PIPE} = "IGNORE" if $SIG{PIPE} eq "DEFAULT"; + =head1 NAME C<IO::Async::Loop> - core loop of the C<IO::Async> framework @@ -133,6 +135,15 @@ Or other subclasses that may appear on CPAN which are not part of the core C<IO::Async> distribution. +=head2 Ignoring SIGPIPE + +Since version I<0.66> loading this module automatically ignores C<SIGPIPE>, as +it is highly unlikely that the default-terminate action is the best course of +action for an C<IO::Async>-based program to take. If at load time the handler +disposition is still set as C<DEFAULT>, it is set to ignore. If already +another handler has been placed there by the program code, it will be left +undisturbed. + =cut # Internal constructor used by subclasses

Sat Apr 04 08:31:35 2015 leonerd-cpan [...] leonerd.org.uk - Status changed from 'open' to 'patched'

Sun Apr 19 12:02:50 2015 leonerd-cpan [...] leonerd.org.uk - Correspondence added

Released in 0.66 -- Paul Evans

Sun Apr 19 12:02:51 2015 leonerd-cpan [...] leonerd.org.uk - Status changed from 'patched' to 'resolved'

Sun Apr 19 12:02:52 2015 leonerd-cpan [...] leonerd.org.uk - Fixed in 0.66 added