[Python-Dev] Ignoring SIGPIPE (original) (raw)

Dave Cole djc at object-craft.com.au
Mon Aug 23 02:01:02 CEST 2004

Guido van Rossum wrote:

I agree, but I think that was copied verbatim from elsewhere in socketmodule.c, so it was left with the aim of being bug for bug compatible with socket.socket().

Indeed. I was not going to change something as fundamental as the existing signal handling. The onyl sensible thing to do was to copy the behaviour already in place when you create a socket the "normal" way. You are correct. There are two places that call signal(SIGPIPE, SIGIGN); I find this surprising. Guido, you added this code in version 1.4 from 1991. You do remember the reason why, don't you? It's only 13 years ago. :-) I'm hesitant to remove the old calls, but I'm not sure I want it added to new calls if it's not necessary. Any opinions? The only real requirement is that SIGPIPE is being ignored by default, and that is already taken care of by inisigs() in pythonrun.c. So I think both calls can be removed from socketmodule.c, heh heh. Originally, I was being careful, and not ignoring SIGPIPE until the first socket was created, hence the call there. The idea being that if you have a Python program that spits lots of stuff to stdout, and you pipe it into head (e.g.), it won't give you an exception -- the SIGPIPE will just kill it and the shell will ignore that; but if you're using sockets, it's important to ignore SIGPIPE so too bad for the other feature. But we've been ignoring SIGPIPE in the initialization forever, so the SIGPIPE call in socketmodule.c is really not needed any more.

So should I remove both signal() calls and go offline for a few months? I should also fix the docstring and documentation to mention that the default socketpair() family is AF_UNIX.

-- http://www.object-craft.com.au

More information about the Python-Dev mailing list