Home Original page

[Python-Dev] Ignoring SIGPIPE (was: [Python-checkins] python/dist/src/Modules socketmodule.c, 1.298, 1.299)

Neal Norwitz neal at metaslash.com
Sat Aug 21 01:40:05 CEST 2004 
On Fri, Aug 20, 2004 at 03:06:21PM +1000, Dave Cole wrote:
> Andrew McNamara wrote:
> >>>Patch #1003700: Add socketpair function to socket module.
> >>
> >>The docstring (below) states the arguments are the same as socket().
> >>However, in sock_initobj() line 2496, the family is initialized to
> >>AF_INET.  I think the #if defined(AF_UNIX) code above should be
> >>removed and family should be initialized to AF_INET.
> >
> >I talked Dave into this - AF_UNIX is typically the only address family
> >that is valid for socketpair(). Using AF_INET under linux and OS X
> >results in EOPNOTSUPP.
> 
> Would a change to the documentation and docstring be sufficient it it 
> explained that the default family is AF_UNIX if defined for the 
> platform, AF_INET otherwise?

That would make me happy.  I just don't want the doc/docstring
to lie.  I don't have a problem with it defaulting to AF_UNIX.

> >>I don't think the #ifdef SIGPIPE code is correct.  If the user
> >>installed a signal handler calling signal() will remove it.  I 
> >>think the call to signal() should be removed.
> >
> >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?

Neal
More information about the Python-Dev mailing list