[Python-Dev] Ignoring SIGPIPE

[Dave Cole]

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, SIG_IGN); 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.

- Dave

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