Bug #454 for Games-Golf: SIGPIPE in aioee()

Sun Apr 07 16:50:43 2002 Guest - Ticket created

Subject:

SIGPIPE in aioee()

Hi guys, Okay, must remember this little piece of information: If you try to read from a pipe, socket, FIFO etc. when the writing end of the connection has been closed, you get an end-of-file indication (read() returns 0 bytes read). If you try and write to a pipe, socket etc. when the reading end has closed, then a SIGPIPE signal will be delivered to the process, killing it unless the signal is caught. (If you ignore or block the signal, the write() call fails with EPIPE.) from: http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC27 and do something about it. There are several similar issues with signals in my code, need to research the possibilities. Jonathan Paton

Sat May 11 08:40:32 2002 Guest - Correspondence added

From:

jonathanpaton [...] yahoo.com

The random failures of the testsuite appear to be caused by SIGPIPE. Adding: $SIG{PIPE} = sub { die "Call a plumber!" }; will randomly be triggered during the test suite. In several places we can die out of the inner eval, and hence out of the scope of the filehandles storing our pipes. Perl automatically closes the pipes, and hence the SIGPIPE signals. Fixing this requires making yet more adjustments to the program flow. At the moment (CVS), the inner structure looks like: eval { # Install signal handliers # Create filehandles # Read and write # Reap } I think it would be possible to die in this structure, and die over our signal handliers... depending on how fast the signal reaches us. This issue is solvable, not it isn't a trival flow issue. We need to consider that we could get SIGPIPE, followed very shortly afterwards by SIGCHLD. As yet, I don't know how long after an event a signal could be received for - either instanteuously or very short period. The problem gets even tougher if it's the latter, as we need to ensure there is no possiblity of leaving our eval{} scopes when a SIG could still occur. Maybe some slumber might help (sleep). This requires more investigation into how signals work, and some serious head banging [off a nearby wall] to fix. It is very difficult to mentally black-box sections of code when they can produce nasty signals. _capture_unix will swallow several more hours of effort! Jonathan Paton

Sun Aug 17 19:15:54 2003 book [...] cpan.org - Status changed from 'new' to 'resolved'