A couple of more things:
This, so far as I can tell is a bug in the FastCGI implementation (Not handling SIGPIPE as suggested). Should I report it somewhere?
The bit you passed along from the FastCGI website seems to intimate that the behavior is expected... I'm not sure where you would report it. ;-)
Python installs a small number of signal handlers by default: SIGPIPE is ignored (so write errors on pipes and sockets can be reported as ordinary Python exceptions)
I didn't know this. It appears Python already installs SIG_IGN as the signal handler for a SIGPIPE signal... mm. I'm not sure how your configuration manages to get around this. I'd have to guess that some product is resetting the signal handler.
And finally, how do I "ignore" a signal ? I guess just writing a "pass" will work ? I'll try it out, I guess on reception of a signal, only one handler is a called once?
import signal signal.signal(signal.SIGPIPE, signal.SIG_IGN) This installs a null signal handler for the SIGPIPE signal. I wonder if you could find the place in the code where the exception occurs when you click a lot and place a "print signal.getsignal(signal.SIGPIPE)" right before the place that the error happens. See if it's 1. If it's 1... well, I'm not sure. I dont know how the process could be killed by a SIGPIE then. If it's 0, that means that something has installed a signal handler on top of Python's default "ignore SIGPIPE" signal handler, and you might be able to find it by grepping for "SIGPIPE" or "13" in your code. - C