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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4